Domotica met plc's

[Basti504]

aaahaaap schreef op zaterdag 28 maart 2020 @ 21:53:
[...]

Kort door de bocht ben ik een "moderne" software development werkwijze gewend (dus sources in git, bouwen via CLI en automatisch deployen) en ditzelfde principe is ook een vereiste voor m'n home automation setup. Dit is iets dat erg ver af lijkt te staan van de software om PLCs meete programmeren die ik tot nu toe heb gezien. Ik hoop dat ik hiermee niemand voor de schenen schop, maar het voelt allemaal een beetje als 10+ jaar geleden :x

[...]

Beetje offtopic, maar als PLC programmeur van beroep kan ik dit alleen bevestigen en ben ik niet op mijn tenen getrapt .

Het is een feit dat de programma's waarmee wij werken enorm achterlopen op moderne software development voor PC's. Zowel in de ontwikkelomgeving zelf, als de programmeertalen. Dan werken wij voornamelijk met Siemens Step 7, Siemens TIA portal en Allen Bradley Controllogix, die opgelegd worden door de eindklant.

Maar omdat de PLC code vaak ook aan de eindklant (fabriek) geleverd wordt samen met de machine die ze kopen, kan ik me voorstellen dat juist de eenvoud van de GUI een voordeel is. De mensen bij de eindklant waar ik mee te maken heb zijn vaak geen volwaardige programmeur en zijn al blij dat ze gewoon "online" kunnen en kijken wat de code doet.

Ik vind het wel interessant om te lezen dat PLC's serieus ingezet worden voor home automation, geeft er ook een andere kijk op.

[UglyDinosaur]

Ik heb ondertussen een antwoord gekregen van Codesys op de vraag of versie 15 van de FW voor de PFC200 compatibel is.

"yes you need to use 3.5SP15Patch4 Package / plc runtime version then it will work."

[aaahaaap]

thomke schreef op zondag 29 maart 2020 @ 10:51:
[...]
PLC met de 'modernste' programeer interface zijn die van Beckhoff..
Beckhoff is gewoon in visual studio te programeren.. en Beckhoff plc's zijn eigenlijk 'Soft PLC's) wat wil zeggen dat je de ontwikkelomgeving ook perfect op de plc zelf kunt draaien (wat wel windows is) maar je hebt dan in principe geen aparte windows pc meer nodg...

Bedankt voor de info. Had nog niet naar de PLCs van Beckhoff gekeken. Moet zeggen dat ik het niet echt kan vinden op hun site :x Alleen maar dingen over software zoals dit http://www.beckhoff.nl/open.htm?page=twincat/default.htm? Heb je misschien een voorbeeld van een specifieke PLC die zo werkt?

AUijtdehaag schreef op zondag 29 maart 2020 @ 11:06:
@aaahaaap Al eens naar node-red gekeken?
YouTube: Read Write Data on Siemens PLC using Node-RED (S7)
Kan zowel met een LOGO! als s7-1200

Node-red verbind zo een beetje alles met elkaar.
Ik gebruik het icm modbus, modbus tcp/ip, MBus, JSON, MQTT, domoticz, S7 logo!, Influxdb en Grafana.
(HA gebruik ik weer niet )

Bedankt voor de suggestie. Node-RED ben ik mee bekend, in het verleden wel eens mee gespeeld maar gaf de voorkeur aan puur programmeren (in het geval van HomeAssistant dmv Python via AppDaemon) over de flows/JSON/Javascript van Node-RED.
En voor zover ik het begrepen heb werken de S7 integraties allemaal via polling? Ik neem aan dat je https://flows.nodered.org/node/node-red-contrib-s7comm of https://flows.nodered.org/node/node-red-contrib-s7 gebruikt?
Mijn voorkeur gaat uit naar event-driven/dat de PLC naar MQTT publisht bij een state change.
Dit is mss meer een theoretisch voordeel dan dat het in de praktijk uitmaakt. Wat is jouw ervaring met deze setup? Is het stabiel? Heb je last van vertragingen soms?

[AUijtdehaag]

@aaahaaap Eerlijk gezegd hangt er een logotje in de meterkast, maar ik weet niet wat ik er mee ga doen (nog)
Alles krijg ik voor elkaar zonder die PLC.
Verder dan wat uitgangetjes aansturen vanuit node-red ben ik nog niet gekomen (omdat het laag op de prio lijst staat)

[ Voor 27% gewijzigd door AUijtdehaag op 29-03-2020 12:19 ]

[tinus5]

thomke schreef op zondag 29 maart 2020 @ 10:51:
Zelf heb ik een vraag voor de rest van dit forum..
Wat gebruiken jullie voor 'branddetectie'? welke rookmelders (of bij voorkeur rooksensoren) gebruiken jullie?
bij voorkeur een rooksensor die gewoon op een digitale ingang van de plc kan aangesloten worden..
(beetje als de losse AMN31112J PIR sensor , maar dan voor rookmelding zonder reeds vast te zitten aan een of andere grote lompe opbouw behuizing.. )

Bedankt!

Ik gebruik gewoon standaard Hager TG501A (3 stuks) en 1 hittemelder (voor de garage). deze zijn allemaal gekoppeld (nieuwbouw). Daarbij een Hager TPG581 interface voor de link met de PLC.

[Kanze]

[b]aaahaaap in "Domotica met plc's"Kort door de bocht ben ik een "moderne" software development werkwijze gewend (dus sources in git, bouwen via CLI en automatisch deployen) en ditzelfde principe is ook een vereiste voor m'n home automation setup. Dit is iets dat erg ver af lijkt te staan van de software om PLCs mee te programmeren die ik tot nu toe heb gezien. Ik hoop dat ik hiermee niemand voor de schenen schop, maar het voelt allemaal een beetje als 10+ jaar geleden :x
Daarnaast draaien al m'n PCs op Linux en heb ik dus niks aan Windows only programma's. WINE is eventueel een optie maar de vraag is of dat goed werkt voor alle functionaliteit.
Op dit vlak lijkt een programmerbare controller (op basis van bijvoorbeeld Arduino) een stuk normaler/prettiger om mee te werken, je werkt aan je sources in je favoriete editor, commit ze, runt `make` of `platformio run` en je krijgt een gecompilde firmware voor op je controller.

Anyway, lang verhaal, om het conreet te maken, dit zijn de vragen die ik heb:
- Is het mogelijk op zo'n manier te werken met PLCs? Heeft iemand hier ervaring mee?
- Is er Linux compatible software om PLCs te programmeren?
- Zijn er CLI tools om de code voor de PLC te valideren en te uploaden naar de PLC?
- Heeft er iemand gekozen voor een microcontroller gebaseerd systeem ipv een PLC? Zo ja, hoe bevalt het? Of, als je daarna alsnog geswitcht bent naar een PLC, wat beviel er niet?

De software is Windows only maar waarom sukkelen met WINE als je gewoon een virtual machine kan opzetten met de nodige ontwikkelingsomgevingen. Hier draait éCockpit exclusief in een VM. Veel PLC's kunnen via ethernet benaderd worden en voor de situaties waar dat niet mogelijk is doe je een passthrough van de USB of seriële kabel. Die opzet heeft ook als voordeel dat je allerhande trial software (zoals éCockpit) gewoon kan gebruiken zonder limieten in de tijd. Als je trial verlopen is doe je een rollback en een minuutje later ben je weer vertrokken voor 30 dagen. Zo doen wij dat hier ook met AUTOCAD bijvoorbeeld. Ik heb geen weet van CLI tools voor WAGO PLC's. Misschien is mogelijk van CODESYS te benaderen via een CLI interface maar ook daar heb ik geen ervaring mee.

Wij gaan hier gebruik maken van ATTiny microchips voor het sensornetwerk. Je kan in principe een domotica systeem opzetten met je eigen gebakken microcontroller zoals een Cortex chip maar dat is toch iets té die-hard voor mij

thomke schreef op zondag 29 maart 2020 @ 10:51:
Zelf heb ik een vraag voor de rest van dit forum..
Wat gebruiken jullie voor 'branddetectie'? welke rookmelders (of bij voorkeur rooksensoren) gebruiken jullie?
bij voorkeur een rooksensor die gewoon op een digitale ingang van de plc kan aangesloten worden..
(beetje als de losse AMN31112J PIR sensor , maar dan voor rookmelding zonder reeds vast te zitten aan een of andere grote lompe opbouw behuizing.. )

Bedankt!

Wij voorzien rookmelders van GIRA die zowel rook als hitte kunnen detecteren. Je koopt per melder een bijkomende relais-module die twee relais kan schakelen voor alarm en systeemfout. Dat gaat dan op een DI van de PLC.

[Mschamp]

aaahaaap schreef op zondag 29 maart 2020 @ 12:13:
[...]

Bedankt voor de info. Had nog niet naar de PLCs van Beckhoff gekeken. Moet zeggen dat ik het niet echt kan vinden op hun site :x Alleen maar dingen over software zoals dit http://www.beckhoff.nl/open.htm?page=twincat/default.htm? Heb je misschien een voorbeeld van een specifieke PLC die zo werkt?

https://www.beckhoff.com/.../cx.htm?id=15987759973374
Alle PLC's van Beckhoff werken zo. Je kan hier kiezen, afhankelijk van welke kracht je er in wil

[MichVw]

aaahaaap schreef op zaterdag 28 maart 2020 @ 21:53:
Goedenavond allen, volg dit topic al een tijdje en ben de zoveelste met wat vragen Hoop dat jullie me een beetje op weg kunnen helpen.

Ik ben van plan m'n domotica setup te updaten van de huidige draadloze (zigbee + MQTT) configuratie naar een bedrade setup waarbij de primaire logica (schakelaar a schakelt lampen x en y, etc) in de centrale controller zit en de controller acteert op MQTT berichten en zijn state naar MQTT publisht. Hierbij zal de "higher level" logica via iets als Home Assistant gedaan worden.
Hiervoor overweeg ik gebruik te maken van PLCs of van een programmeerbare controller (waarschijnlijk Arduino based, voornamelijk omdat ik verder eigenlijk geen andere opties ben tegengekomen) en ik vroeg me af wat jullie mening hierover is.

Kwa hardware gaat m'n voorkeur uit naar PLCs, met name vanwege de hoge mate van betrouwbaarheid en de kant en klare bouwblokken en integraties die geen grote tijdsinvestering aan de softwarekant nodig hebben. De modulariteit zie ik, ondanks m'n relatief bescheiden requirements kwa inputs en outputs, ook als een pluspunt.
Daarnaast biedt de opzet van @MichVw zo te zien een gode start voor de functionaliteit die ik zoek.

De softwarekant lijkt helaas een heel ander verhaal. Ten eerste zie ik voor nagenoeg alle PLC's alleen maar GUI programma's die ook nog eens alleen maar beschikbaar zijn voor Windows. De Siemens LOGO! controllers lijken hierop de uitzondering door hun JAVA gebaseerde software maar die ondersteunen voor zover ik heb kunnen vinden weer geen MQTT.

Kort door de bocht ben ik een "moderne" software development werkwijze gewend (dus sources in git, bouwen via CLI en automatisch deployen) en ditzelfde principe is ook een vereiste voor m'n home automation setup. Dit is iets dat erg ver af lijkt te staan van de software om PLCs mee te programmeren die ik tot nu toe heb gezien. Ik hoop dat ik hiermee niemand voor de schenen schop, maar het voelt allemaal een beetje als 10+ jaar geleden :x
Daarnaast draaien al m'n PCs op Linux en heb ik dus niks aan Windows only programma's. WINE is eventueel een optie maar de vraag is of dat goed werkt voor alle functionaliteit.
Op dit vlak lijkt een programmerbare controller (op basis van bijvoorbeeld Arduino) een stuk normaler/prettiger om mee te werken, je werkt aan je sources in je favoriete editor, commit ze, runt `make` of `platformio run` en je krijgt een gecompilde firmware voor op je controller.

Anyway, lang verhaal, om het conreet te maken, dit zijn de vragen die ik heb:
- Is het mogelijk op zo'n manier te werken met PLCs? Heeft iemand hier ervaring mee?
- Is er Linux compatible software om PLCs te programmeren?
- Zijn er CLI tools om de code voor de PLC te valideren en te uploaden naar de PLC?
- Heeft er iemand gekozen voor een microcontroller gebaseerd systeem ipv een PLC? Zo ja, hoe bevalt het? Of, als je daarna alsnog geswitcht bent naar een PLC, wat beviel er niet?

Hey, mijn dag dagelijkse bezigheden in de IT sector werken ook volledig met automated deployment en zeker akkoord dat bij PLC software daar nog flink wat werk is. Ik heb in het verleden nog een mailtje gestuurd naar Wago support om te vragen of ze geen Docker container hadden met de nodige tools om een é!cockpit project automatisch te builden maar het antwoord kan je al raden waarschijnlijk

Codesys heeft de codesys automation server:
https://www.automation-server.com/en/

Maar los van het feit dat het betalend is vind ik het ook wat overkill.. Vooral omdat je gebruikt maakt van de Codesys 3S infrastructuur en niet een docker container bijvoorbeeld die je eender waar kunt draaien.

Langs de andere kant vind ik ook wel wat dat je het anders moet bekijken, zeker als je eventueel van plan bent om m'n reference project te gebruiken: Het idee is om enkel kerntaken te gaan uitvoeren in de PLC, complexe automatisaties erbuiten. Als je dat als uitgangspunt neemt zou het niet de bedoeling mogen zijn dat je veel de PLC software update. Enkel als er hardware bijkomt (zoals RS845 devices) maar anders niet.. wat ga je anders doen? om de X tijd de schakelaar veranderen waarmee je een licht aansteekt?

Met dat standpunt lijkt het me interessanter om de software laag boven de PLC te gaan benaderen met automated CI/CD. En aangezien alles van die software in docker containers kan gedraaid worden is dat zeker mogelijk..

Bijvoorbeeld een docker Azure DevOps agent draaien in je netwerk en dan daarmee je andere docker containers deployen/beheren.. Zeer veel mogelijk

[aaahaaap]

MichVw schreef op maandag 30 maart 2020 @ 10:52:
[...]


Hey, mijn dag dagelijkse bezigheden in de IT sector werken ook volledig met automated deployment en zeker akkoord dat bij PLC software daar nog flink wat werk is. Ik heb in het verleden nog een mailtje gestuurd naar Wago support om te vragen of ze geen Docker container hadden met de nodige tools om een é!cockpit project automatisch te builden maar het antwoord kan je al raden waarschijnlijk

Codesys heeft de codesys automation server:
https://www.automation-server.com/en/

Maar los van het feit dat het betalend is vind ik het ook wat overkill.. Vooral omdat je gebruikt maakt van de Codesys 3S infrastructuur en niet een docker container bijvoorbeeld die je eender waar kunt draaien.

Langs de andere kant vind ik ook wel wat dat je het anders moet bekijken, zeker als je eventueel van plan bent om m'n reference project te gebruiken: Het idee is om enkel kerntaken te gaan uitvoeren in de PLC, complexe automatisaties erbuiten. Als je dat als uitgangspunt neemt zou het niet de bedoeling mogen zijn dat je veel de PLC software update. Enkel als er hardware bijkomt (zoals RS845 devices) maar anders niet.. wat ga je anders doen? om de X tijd de schakelaar veranderen waarmee je een licht aansteekt?

Met dat standpunt lijkt het me interessanter om de software laag boven de PLC te gaan benaderen met automated CI/CD. En aangezien alles van die software in docker containers kan gedraaid worden is dat zeker mogelijk..

Bijvoorbeeld een docker Azure DevOps agent draaien in je netwerk en dan daarmee je andere docker containers deployen/beheren.. Zeer veel mogelijk

Bedankt voor je antwoord. Jammer dat WAGO hier geen betere oplossing voor heeft. Ze hebben wel open-source en git(hub) ontdekt en hebben zelfs de sources om het (Linux) OS voor de PFC100/200 te bouwen online gezet (https://github.com/WAGO/pfc-firmware-sdk). Helaas hebben ze niet iets soortgelijks voor de programmeersoftware.

Overigens bood die repo + dit voorbeeld wel wat aanknopingspunten voor alternatieve oplossingen. Ze gebruiken blijkbaar kbus en dat is op zich wel uit te lezen met zelfgeschreven software die op de PLC draait. Vraag me alleen af dat niet een beetje voorbij gaat aan de reden om een PLC te kiezen. Ik gok dat een groot deel van wat een WAGO PLC een WAGO PLC maakt de (userspace) software is waar je tegenaan programmeert en dat hiet zozeer om het feit gaat dat het een (realtime) Linux machine is.

Wat betreft je punt van weinig/minder veranderingen aan de code/config van de PLC: Fair enough, dat lijkt me, zeker als de basics een beetje rond zijn wel een mogelijkheid. M'n huidige (Home-Assistant) setup heb ik ook al maanden niet aangeraakt omdat het allemaal werkt.
Aan de andere kant ben je zeker in het begin toch wel vaak bezig met (veel) al dan niet kleine wijzigingen, dat zal elke developer die aan iets nieuws begint wel kunnen beamen
Wat is jouw persoonlijke ervaring op dit vlak met de door jou gemaakte libraries en je eigen PLC config?

[MichVw]

aaahaaap schreef op maandag 30 maart 2020 @ 20:19:
[...]

Bedankt voor je antwoord. Jammer dat WAGO hier geen betere oplossing voor heeft. Ze hebben wel open-source en git(hub) ontdekt en hebben zelfs de sources om het (Linux) OS voor de PFC100/200 te bouwen online gezet (https://github.com/WAGO/pfc-firmware-sdk). Helaas hebben ze niet iets soortgelijks voor de programmeersoftware.

Overigens bood die repo + dit voorbeeld wel wat aanknopingspunten voor alternatieve oplossingen. Ze gebruiken blijkbaar kbus en dat is op zich wel uit te lezen met zelfgeschreven software die op de PLC draait. Vraag me alleen af dat niet een beetje voorbij gaat aan de reden om een PLC te kiezen. Ik gok dat een groot deel van wat een WAGO PLC een WAGO PLC maakt de (userspace) software is waar je tegenaan programmeert en dat hiet zozeer om het feit gaat dat het een (realtime) Linux machine is.

Wat betreft je punt van weinig/minder veranderingen aan de code/config van de PLC: Fair enough, dat lijkt me, zeker als de basics een beetje rond zijn wel een mogelijkheid. M'n huidige (Home-Assistant) setup heb ik ook al maanden niet aangeraakt omdat het allemaal werkt.
Aan de andere kant ben je zeker in het begin toch wel vaak bezig met (veel) al dan niet kleine wijzigingen, dat zal elke developer die aan iets nieuws begint wel kunnen beamen
Wat is jouw persoonlijke ervaring op dit vlak met de door jou gemaakte libraries en je eigen PLC config?

Akkoord met de beginfase, alhoewel ik denk dat het toch minimaal zou moeten zijn. Zelf zit ik nog niet in een verbouwing/bouw situatie. Dit is allemaal (zeer grondige ) voorbereiding. Ik heb wel een testbench draaien met 2 PLC's: één codesys 3S runtime en één éCOCKPIT runtime. Daar dien ik enkel aanpassingen te doen als ik bezig ben met nieuwe features of zaken uit te proberen. Er zijn wel al mensen die de setup gebruiken in hun huis en daar krijg ik bijzonder weinig/geen klachten van. Enkele mensen zitten hier op het forum maar je vind ze ook terug op de GITTER chat:
https://gitter.im/Michiel...e/HomeAutomation.CoDeSys3
Je kan je vraag gerust dus ook eens daar stellen...

[Kanze]

Vandaag eindelijk RS485 communicatie opgestart gekregen tussen de PLC en een Eastron SDM220.

Dank aan forumlid @MichVw om me op weg te brengen met wat beeldmateriaal. Uiteindelijk bleek dat ik een GND connectie verkeerd had aangesloten. Voor zij die zelf aan de slag willen met de on-board serial interface hieronder de bedrading van de connector.

Daarbij is Blauw RS485 A (DB9 pin 3) en Blauw/Wit RS485 B (DB9 pin 8 ). Ik had eerst Oranje/Wit aangesloten op DB9 pin 5 omdat die overeenkomt met de PLC GND pin op de on-board serial. Dat wilde dus niet werken. Dan maar aangesloten op DB GND pin.

De resistorketting is 120 Ohm.

[Kanze]

Hier heb ik de bekende Alibaba DMX302 dimmer aangestuurd gekregen via een 750-652 seriële module als DMX master.

[UglyDinosaur]

Antonius schreef op zondag 1 maart 2020 @ 11:37:
[...]


Dat zou ik wel interessant vinden om te horen. Normaliter doet PLC code niet aan dynamische geheugen allocatie. Dat komt de stabiliteit ten goede. Als jouw PLC wel langzaam minder vrij geheugen krijgt tot een reboot dan is er iets bijzonders aan de hand.

OK, dat is dus inderdaad wel het probleem. Sinds ik firmware 12 op de PLC heb gezet heb ik het programma terug op het interne geheugen van de PLC kunnen zetten (in plaats van de de SD kaart zoals ervoor). Nu zie ik dat het RAM geheugen (de 256MB) langzaamaan volloopt over een periode van ongeveer 5 dagen. Eenmaal vol blijft de PLC gewoon hangen en doet hij niets meer...

Als er iemand tips moest hebben...

[Antonius]

Ik weet niet meer zeker of jij 3S Codesys firmware draait of Wago. Als je Wago firmware en E!Cockpit gebruikt dan vermoed ik een firmware probleem. Ik heb een tijdje terug ook een paar klanten gehad waar zo nu en dan de PLC na een tijdje vast leek te lopen. Na een power cycle werkt de PLC weer. Normaal gesproken moeten ze lange tijd stabiel blijven draaien (uptime van maanden is geen uitzondering als de stroomvoorziening goed is). Je kunt je PLC firmware flashen naar de meest recente. Huidige firmware is versie 15. Zo te krijgen bij Wago, E!Cockpit update haalt hem vanzelf op als je dat aan hebt staan, en de Wago firmwares staan tegenwoordig ook op github als ik met niet vergis.

[MichVw]

UglyDinosaur schreef op zaterdag 4 april 2020 @ 09:41:
[...]


OK, dat is dus inderdaad wel het probleem. Sinds ik firmware 12 op de PLC heb gezet heb ik het programma terug op het interne geheugen van de PLC kunnen zetten (in plaats van de de SD kaart zoals ervoor). Nu zie ik dat het RAM geheugen (de 256MB) langzaamaan volloopt over een periode van ongeveer 5 dagen. Eenmaal vol blijft de PLC gewoon hangen en doet hij niets meer...

Als er iemand tips moest hebben...

Welke runtime gebruik je weer? was dat Codesys 3S of de é!runtime? ergens is er (in beide) een parameter die aangeeft hoeveel dynamische ram die je programma mag gebruiken in je PLC. zeker eens de moeite om na tekijken. Als je me meegeeft welke runtime je gebruikt wil ik het zeker wel eens opzoeken ook..

Los daarvan: welke libraries gebruik je zo allemaal? Ik weet dat één van je libraries van source forge komt (de MQTT lib), smijt die er eventueel eens even uit en valideer eens na 2 dagen of het memory nog toenoeemt? Indien niet, misschien eens de HVAC library proberen? Ik denk dat we net een periode zitten/komen waar je die sowieso minder/niet nodig hebt? (als het enkel voor verwarmining word gebruikt toch). En dan nog, als ik het goed heb kan je binnen de 2 dagen valideren, misschien even boiler manueel aansturen dan...?

Niet leuk, ik weet het maar het proberen waard?

[UglyDinosaur]

MichVw schreef op maandag 6 april 2020 @ 08:48:
[...]


Welke runtime gebruik je weer? was dat Codesys 3S of de é!runtime? ergens is er (in beide) een parameter die aangeeft hoeveel dynamische ram die je programma mag gebruiken in je PLC. zeker eens de moeite om na tekijken. Als je me meegeeft welke runtime je gebruikt wil ik het zeker wel eens opzoeken ook..

Los daarvan: welke libraries gebruik je zo allemaal? Ik weet dat één van je libraries van source forge komt (de MQTT lib), smijt die er eventueel eens even uit en valideer eens na 2 dagen of het memory nog toenoeemt? Indien niet, misschien eens de HVAC library proberen? Ik denk dat we net een periode zitten/komen waar je die sowieso minder/niet nodig hebt? (als het enkel voor verwarmining word gebruikt toch). En dan nog, als ik het goed heb kan je binnen de 2 dagen valideren, misschien even boiler manueel aansturen dan...?

Niet leuk, ik weet het maar het proberen waard?

Bedankt voor het antwoord, maar mogelijk heb ik een andere oplossing gevonden... Ik heb er enkele dagen geleden een lege SD kaart in gestoken en herstart... Voorlopig geen probleem meer met het geheugen...
Mogelijk probeerde het programma toch iets weg te schrijven naar de kaart maar bleef dit in het geheugen zitten??

[Rob Z]

Vrij oude quote over NOVRAM in Wago fieldbus controllers:

frv schreef op woensdag 29 november 2017 @ 13:32:
[...]
Foefjes zoals NOVRAM gebruiken daarvoor zou ik toch voor passen (Dat geheugen is daar niet voor bedoeld)

http://www.wago.us/appnot...s%20and%20Controllers.pdf

Zie p14 en 15
[...]

Het genoemde document kan ik zo vlot niet meer vinden.

@frv Kun je aangeven waarom het NOVRAM geheugendeel niet geschikt is om bijvoorbeeld vanaf Home-Assistant te benaderen?
Is er kans op een adresconflict met Retain variabelen? Of is het van fysieke aard?

[Ethirty]

Iemand ervaringen met weer-sensoren? Ik zie her en der wat voorbeelden om weer-input op je plc te gebruiken als sturing voor zonwering, beregening etc.

Maar als ik bijv hier kijk, dan schrik ik toch wel van de prijzen van alle benodigde 24V sensoren (wind, regen, lux, temp).

Voor het geld koop je een super de luxe Davis Vantage Pro2 en hoef je niks te puzzelen met het converteren van een 0-10V signaal naar nuttige informatie. Kan je wel niks mee aansturen, maar geeft toch aan dat de bovenstaande sensoren in verhouding veel te duur zijn.

[frv]

Rob Z schreef op dinsdag 7 april 2020 @ 10:00:
Vrij oude quote over NOVRAM in Wago fieldbus controllers:


[...]

Het genoemde document kan ik zo vlot niet meer vinden.

@frv Kun je aangeven waarom het NOVRAM geheugendeel niet geschikt is om bijvoorbeeld vanaf Home-Assistant te benaderen?
Is er kans op een adresconflict met Retain variabelen? Of is het van fysieke aard?

Non-voltatile memory (retain) 32 kByte
NOVRAM Remanent memory (32 kByte)
The remanent memory is a non-volatile memory; i.e., all values of flags and
variables, that are explicitly defined by “var retain”, are retained even after a
loss of power. Memory management is performed automatically. The
32 kByte memory area is normally divided into an 16 kByte addressable
range for flags (%MW0 ... %MW 8191) and a 16 kByte retain area for
variables without memory area addressing, that are defined by "var retain".

Als ik het me goed herinner was het mij meer een kwestie dat het in de handleidingen niet echt aangeraden werd (waarschuwingen ivm wijzigen defaults en/of overlapping) EN dat het voor bijhouden van de status niet echt een geschikte geheugenlocatie is ... hangt er natuurlijk vanaf wat je precies wil opslaan ...Moet die status een reboot overleven ja dan heb je geen andere keuze dan via dat NOVRAM te werken.

Hoewel ikzelf dan eerder zou naar de SD memory card zou schrijven ... Voorbeelden zat om bv csv bestanden aan te maken op SD card.

Update : Vond in de specsheet van een andere type PLC dat het retain memory slechts een beperkt aantal schrijfcycli heeft. Lijkt me dan logischer de SD kaart te gebruiken die je makkelijk kan vervangen indien nodig.

https://cdn.automationdir.../manuals/d2user/appxe.pdf

Data values that must be retained for long periods of time, when the PLC is powered off,
should be stored in EEPROM-based V-memory. Since EEPROM is limited to the number
of times it can be written to, it is suggested that transitional logic, such as a one-shot, be used
to write the data one time, instead on each CPU scan.
Data values that are continually changing or which can be initialized with program logic
should be stored in RAM-based V-memory

[ Voor 39% gewijzigd door frv op 07-04-2020 16:30 ]

[Kanze]

Ethirty schreef op dinsdag 7 april 2020 @ 15:09:
Iemand ervaringen met weer-sensoren? Ik zie her en der wat voorbeelden om weer-input op je plc te gebruiken als sturing voor zonwering, beregening etc.

Maar als ik bijv hier kijk, dan schrik ik toch wel van de prijzen van alle benodigde 24V sensoren (wind, regen, lux, temp).

Voor het geld koop je een super de luxe Davis Vantage Pro2 en hoef je niks te puzzelen met het converteren van een 0-10V signaal naar nuttige informatie. Kan je wel niks mee aansturen, maar geeft toch aan dat de bovenstaande sensoren in verhouding veel te duur zijn.

Er wordt hier gewerkt aan een multi-purpose sensorkit op basis van een ATTiny chip zoals de 3216. Op die kit kunnen dan alle gewenste sensoren aangesloten worden en het ding kan ingebouwd worden (of opgebouwd) waar nodig. De kit praat dan met je PLC via RS485. Met een enkele (betaalbare) seriële klem als een 750-652 kan je dan heel je sensornetwerk uitlezen.

Momenteel zijn ik en @MichVw hier mee bezig. Echter, ik heb ook een werf lopen, en die sensors zijn iets dat bij mij pas in een tweede fase zal worden geplaatst. Verwacht dus nog geen kant en klare oplossing op de korte termijn.

Als tijd geen probleem is raad ik je aan dit project te blijven volgen. Het grote voordeel is dat je de kit compleet kan afstemmen op wat jij nodig hebt en dat hij een fractie zal kosten van wat je off the shelf kan kopen.

Wil je liever een product dat je zo in de winkel kan kopen vrees ik dat je zal moeten betalen. Dat was ook de reden dat dit project is gestart. ik ga zo'n 30 van die dingen plaatsen -- dat was niet te betalen als ik het niet zelf maak.

[Ethirty]

Interessant.

En waarom dan niet via Modbus of een ander (netwerk) protocol? Niet iedereen kan of wil een full blown PLC met Codesys draaien.

Iemand had het hier recent over verouderde technieken en protocollen, serieel hoort dat imo ook wel bij. Of snap ik nog te weinig van wat jullie van plan zijn en praat ik onzin?

[MewBie]

Ethirty schreef op dinsdag 7 april 2020 @ 19:17:
Interessant.

En waarom dan niet via Modbus of een ander (netwerk) protocol? Niet iedereen kan of wil een full blown PLC met Codesys draaien.

Iemand had het hier recent over verouderde technieken en protocollen, serieel hoort dat imo ook wel bij. Of snap ik nog te weinig van wat jullie van plan zijn en praat ik onzin?

Modbus RTU gebruikt RS485.

[Ethirty]

MewBie schreef op dinsdag 7 april 2020 @ 19:25:
[...]

Modbus RTU gebruikt RS485.

RTU wel ja, ik had het over Modbus TCP.

[Kanze]

Ethirty schreef op dinsdag 7 april 2020 @ 19:17:
Interessant.

En waarom dan niet via Modbus of een ander (netwerk) protocol? Niet iedereen kan of wil een full blown PLC met Codesys draaien.

Iemand had het hier recent over verouderde technieken en protocollen, serieel hoort dat imo ook wel bij. Of snap ik nog te weinig van wat jullie van plan zijn en praat ik onzin?

Wel je zit in het topic "Domotica met PLC's" dus antwoorden die je hier krijgt zijn met een PLC omgeving in het achterhoofd.

Je vraag over Modbus moet je eigenlijk omgekeerd stellen. Waarom een volledige TCP/IP stack implementeren voor het uitlezen van enkele registers op een microchip? Hoe eenvoudiger de opstelling hoe minder er kan fout gaan.

[Ethirty]

Omdat ik en wellicht anderen meer zien in de eenvoud van een Siemens Logo of Eaton Easy achtige oplossing.

Alleen kom ik er steeds weer achter dat eenvoud duur is

[MichVw]

Ethirty schreef op dinsdag 7 april 2020 @ 19:17:
Interessant.

En waarom dan niet via Modbus of een ander (netwerk) protocol? Niet iedereen kan of wil een full blown PLC met Codesys draaien.

Iemand had het hier recent over verouderde technieken en protocollen, serieel hoort dat imo ook wel bij. Of snap ik nog te weinig van wat jullie van plan zijn en praat ik onzin?

Ik begrijp de vraag maar als je de richting uit wilt gaan van een protocol op de TCP/IP stack dan moet je al kijken voor een controller die dat aankan ook. Kostprijs en complexiteit gaan de lucht in en wat is het voordeel?

Toegegeven, Modbus RTU is een ouder protocol maar dat wil ook zeggen dat het zichzelf al lang bewezen heeft & het heeft ook als groot voordeel dat het rechtstreeks op de PLC kan worden uitgelezen, geen extra componenten die mogelijk kunnen falen. Een hoop libraries beschikbaar voor implementatie op de microcontroller en door z'n eenvoud niet veel compute resources nodig wat helpt om de PCB klein te houden..

Net zoals met PLC's draait het hier om betrouwbaarheid en gebruik op lange termijn (10 jaar +) en een bedrade aanpak, dan is modbus RTU geen slechte keuze denk ik.

Enige wat er van gezegd kan worden is dat het polling based is wat niet erg is voor sensoren zoals temperatuur enz, voor beweging kan dat een andere zaak zijn, zou ik dan persoonlijk rechtsreeks op een digitale input klem steken van de PLC.

[Fraggar]

Kanze schreef op dinsdag 7 april 2020 @ 18:40:
Als tijd geen probleem is raad ik je aan dit project te blijven volgen. Het grote voordeel is dat je de kit compleet kan afstemmen op wat jij nodig hebt en dat hij een fractie zal kosten van wat je off the shelf kan kopen.

Interessant project wat ik zeker volg! Dit om aan te geven dat hier zeker interesse voor is en ik zeker niet de enige zal zijn.

[DeadLock]

Ik ben hier momenteel druk in de weer met elektriciteit en domotica in mijn kleine huisje. De elektriciteitskast is grotendeels bekabeld ondertussen, echter de "domotica kast" ernaast heb ik nog wat moeite om gestart te raken.

Het is een normale 72 module kast (4 rijen), waar alle 5g1.5 xvb's binnen komen van de verlichting (led/laagspanning), eveneens de 16 aderige svv kabels en enkele cat6 voor sensors. Waar een 72 module kast eerst 'gigantisch' leek, denk ik dat ik zeer selectief ga moeten zijn wat er weg te hangen .

Omdat ik er nog nooit mee in aanraking gekomen ben, vraag ik mij af wat de beste manier is om alle binnenkomende kabels mooi af te monteren op etageklemmen. Idealiter neemt dit zo min mogelijk plek in beslag in de kast, om voldoende plaats over te houden voor het domotica aspect en de led-drivers.

Ik heb een 25-tal 5g1.5 kabels van de verlichting en een 15-tal drukknoppen om af te monteren (vooral 4- en 6 voudige).

En wat voor draad gebruik ik vervolgens tussen de etage-klemmen en de led-drivers bvb? En tussen etageklem van drukknoppen/svv/sensors en de inputs van domotica?

Heeft er iemand een kleine aanzet zodat ik een beetje een beter idee heb hoe het bekabelen het beste aan te pakken?

[thomke]

DeadLock schreef op donderdag 9 april 2020 @ 07:44:
Ik ben hier momenteel druk in de weer met elektriciteit en domotica in mijn kleine huisje. De elektriciteitskast is grotendeels bekabeld ondertussen, echter de "domotica kast" ernaast heb ik nog wat moeite om gestart te raken.

Het is een normale 72 module kast (4 rijen), waar alle 5g1.5 xvb's binnen komen van de verlichting (led/laagspanning), eveneens de 16 aderige svv kabels en enkele cat6 voor sensors. Waar een 72 module kast eerst 'gigantisch' leek, denk ik dat ik zeer selectief ga moeten zijn wat er weg te hangen .

Omdat ik er nog nooit mee in aanraking gekomen ben, vraag ik mij af wat de beste manier is om alle binnenkomende kabels mooi af te monteren op etageklemmen. Idealiter neemt dit zo min mogelijk plek in beslag in de kast, om voldoende plaats over te houden voor het domotica aspect en de led-drivers.

Ik heb een 25-tal 5g1.5 kabels van de verlichting en een 15-tal drukknoppen om af te monteren (vooral 4- en 6 voudige).

En wat voor draad gebruik ik vervolgens tussen de etage-klemmen en de led-drivers bvb? En tussen etageklem van drukknoppen/svv/sensors en de inputs van domotica?

Heeft er iemand een kleine aanzet zodat ik een beetje een beter idee heb hoe het bekabelen het beste aan te pakken?

properste manier is om uw klemmen waar je uw kabels op aansluit onderaan of bovenaan uw kast voorziet, dan komen uw kabels toe in uw kast, zitten ze direct aan de klemmen (zo bespaar je plaats in de rest van uw kabelgoten) de kablage in uw kast zelf (voor onder andere van uw klemmen naar de drives) zou ik met soepele 'kableerdraad' doen (verkrijgbaar in alle kleuren en alle diameters)

[ Voor 39% gewijzigd door thomke op 09-04-2020 11:15 ]

[thomke]

Dag iedereen!

ik ben zelf niet zo een fan van de modbus rtu oplossing die hier gemaakt wordt voor sensoren uit te lezen (veel te veel pruts werk naar mijn gevoel, alsook een verouderd protocol, die nu in de industrie bij mijn weten zelden nog gebruikt wordt
(profinet, ethercat, .. zijn de protocollen waar ik meest mee in aanraking kom en merk bij nieuwe installaties altijd gebruikt worden)

ik neig zelf naar 1-wire oplossingen (ook oud) maar ik moet dan zelf geen pcbtjes beginnen maken..

ik kwam net dit tegen:
https://sedtronic.eu/en/u...pcb_protection-no_coating

mensen die hier ervaring mee hebben? lijkt mij wel leuk! ook de extra DI die nog beschikbaar is (eventueel nog een pir op te monteren) lijkt mij leuk!

[Kanze]

thomke schreef op donderdag 9 april 2020 @ 11:09:
Dag iedereen!

ik ben zelf niet zo een fan van de modbus rtu oplossing die hier gemaakt wordt voor sensoren uit te lezen (veel te veel pruts werk naar mijn gevoel, alsook een verouderd protocol, die nu in de industrie bij mijn weten zelden nog gebruikt wordt
(profinet, ethercat, .. zijn de protocollen waar ik meest mee in aanraking kom en merk bij nieuwe installaties altijd gebruikt worden)

ik neig zelf naar 1-wire oplossingen (ook oud) maar ik moet dan zelf geen pcbtjes beginnen maken..

ik kwam net dit tegen:
https://sedtronic.eu/en/u...pcb_protection-no_coating

mensen die hier ervaring mee hebben? lijkt mij wel leuk! ook de extra DI die nog beschikbaar is (eventueel nog een pir op te monteren) lijkt mij leuk!

Geen ervaring mee maar het lijkt me eigenlijk gewoon hetzelfde als waar hier aan gewerkt wordt. Alleen kost het natuurlijk wel een stevige duit.

Tenzij ik me vergis is 1-Wire ook een master/slave protocol? Bewegingsmelding op een dergelijk protocol is moeilijk.

Hoe wordt dit aangesloten op de PLC. Via een aparte 1-Wire controller?

[Ethirty]

Kanze schreef op donderdag 9 april 2020 @ 12:39:
[...]


Geen ervaring mee maar het lijkt me eigenlijk gewoon hetzelfde als waar hier aan gewerkt wordt. Alleen kost het natuurlijk wel een stevige duit.

Tenzij ik me vergis is 1-Wire ook een master/slave protocol? Bewegingsmelding op een dergelijk protocol is moeilijk.

Hoe wordt dit aangesloten op de PLC. Via een aparte 1-Wire controller?

1-Wire is volgens mij an sich wel goedkoop. Deed @Femme daar ook niet wat mee?

Je betaalt hier voor een custom printplaat die past in bestaand schakelmateriaal. Als je het vergelijkt met de in- en opbouw sensoren van bijv Esera dan is het zelfs nog relatief goedkoop.

[thomke]

Kanze schreef op donderdag 9 april 2020 @ 12:39:
[...]


Geen ervaring mee maar het lijkt me eigenlijk gewoon hetzelfde als waar hier aan gewerkt wordt. Alleen kost het natuurlijk wel een stevige duit.

Tenzij ik me vergis is 1-Wire ook een master/slave protocol? Bewegingsmelding op een dergelijk protocol is moeilijk.

Hoe wordt dit aangesloten op de PLC. Via een aparte 1-Wire controller?

inderdaad, maar hier heb je al iets dat 'werkt' als je de 'uren' in developing van jullie printje zou aanrekenen zal je ook wel snel in deze buurt komen denk ik? dit leek mij gewoon een mooie tussenoplossing voor prijs/tijd die ik wil spenderen om het te integreren.. (indien het nog goedkopere kan, graag! maar ik wil ook geen uren zitten solderen op pcb'tjes..) ik vermoed niet dat jullie jullie printje op de markt gaan brengen voor mensen te laten kopen?

(het is inderdaad ook een master/slave protocol dacht ik, voor bewegingsmelder zal het inderdaad niet al te handig zijn - er kan dacht ik tot 2s vertraging op zitten.. )

Ethirty schreef op donderdag 9 april 2020 @ 12:47:
[...]

1-Wire is volgens mij an sich wel goedkoop. Deed @Femme daar ook niet wat mee?

Je betaalt hier voor een custom printplaat die past in bestaand schakelmateriaal. Als je het vergelijkt met de in- en opbouw sensoren van bijv Esera dan is het zelfs nog relatief goedkoop.

Femme gebruikt inderdaad ook 1-wire dacht ik.
je betaalt inderdaad vooral de printplaat, in principe zou je ook rechtstreeks losse sensoren op 1-wire kunnen aansluiten, deze sensoren zijn echt spot goedkoop..


dit is dan ook wat ik zou doen, stel op plaatsen (of leidingen) waar ik enkel temperatuur wil uitlezen, kan ik een enkele temperatuursensor voorzien, rechtstreeks op 1-wire aansluiten (zonder printje) en zo heb ik voor een paar euro een temperatuur uitlezen . waar ik meer wil uitlezen dan enkel de sensor zou ik dan eventueel opteren voor zo een reeds 'kant en klaar' printje in de wandschakelaar..

[DeadLock]

thomke schreef op donderdag 9 april 2020 @ 11:00:
[...]


properste manier is om uw klemmen waar je uw kabels op aansluit onderaan of bovenaan uw kast voorziet, dan komen uw kabels toe in uw kast, zitten ze direct aan de klemmen (zo bespaar je plaats in de rest van uw kabelgoten) de kablage in uw kast zelf (voor onder andere van uw klemmen naar de drives) zou ik met soepele 'kableerdraad' doen (verkrijgbaar in alle kleuren en alle diameters)

Dat klinkt inderdaad als een goede opzet. Het uitkiezen van de juiste etageklemmen is nog niet zo eenvoudig.

Ik heb een 'fix-o-rail 150' kast, die eerder beperkt is qua diepte. Ik had bijvoorbeeld de wago 2002-3201 in gedachten, omdat ik dan tenminste 3 aders per klem kan afmonteren, maar die is al net te diep voor deze kast volgens mijn leverancier.

Heeft er iemand een suggestie voor klemmen die mooi passen in deze kast en toch efficiënt mogelijk omgaan met de plaats in de kast?

[Ethirty]

Ben ik ook wel in geïnteresseerd, want dat deel van de hardware-kant is hier een beetje onderbelicht.

Krijg toch de indruk dat velen hier zakelijk met installatietechniek werken, maar voor anderen is het een oerwoud aan partnummers en geen duidelijk beeld welke parts je waarvoor nodig hebt.

[Kanze]

thomke schreef op donderdag 9 april 2020 @ 13:06:
[...]


inderdaad, maar hier heb je al iets dat 'werkt' als je de 'uren' in developing van jullie printje zou aanrekenen zal je ook wel snel in deze buurt komen denk ik? dit leek mij gewoon een mooie tussenoplossing voor prijs/tijd die ik wil spenderen om het te integreren.. (indien het nog goedkopere kan, graag! maar ik wil ook geen uren zitten solderen op pcb'tjes..) ik vermoed niet dat jullie jullie printje op de markt gaan brengen voor mensen te laten kopen?

(het is inderdaad ook een master/slave protocol dacht ik, voor bewegingsmelder zal het inderdaad niet al te handig zijn - er kan dacht ik tot 2s vertraging op zitten.. )

Klopt wat je zegt hoor! Het ontwerpen van die eigen sensors is vooral gemotiveerd door eigen interesse en motivatie. In een dergelijke situatie kijk je niet naar geïnvesteerde tijd als een kost maar als een hobby besteding. Zoiets doe je dus inderdaad niet als het je gewoon te doen is om iets werkende te krijgen.

Dat gezegd zijnde wil ik altijd meedenken aan andere opstellingen en oplossingen. In het geval van een 1-Wire netwerk zou je kunnen werken met een 1-Wire controller van Esera via RS232 of Ethernet.

In de specsheets van die controllers staat wel een lijst met supported chips. Dus nu weet ik niet of die controller ook direct met dat PCB'tje uit je post kan praten?

[thomke]

Ethirty schreef op donderdag 9 april 2020 @ 14:24:
Ben ik ook wel in geïnteresseerd, want dat deel van de hardware-kant is hier een beetje onderbelicht.

Krijg toch de indruk dat velen hier zakelijk met installatietechniek werken, maar voor anderen is het een oerwoud aan partnummers en geen duidelijk beeld welke parts je waarvoor nodig hebt.

dit al eens bekeken?
Femme's Storblog: Smarthome kooptips voor de doe-het-zelver

[Ethirty]

Ja die ken ik, maar legt het verschil maar beperkt uit. En zoals DeadLock al aangaf:

Het uitkiezen van de juiste etageklemmen is nog niet zo eenvoudig.

Dus op zich wel interessant om aan te geven wat je gebruikt en waarom. Neem tenminste aan dat niet iedereen blind hetzelfde heeft besteld als Femme.

[THM0]

Ethirty schreef op donderdag 9 april 2020 @ 16:14:
Ja die ken ik, maar legt het verschil maar beperkt uit. En zoals DeadLock al aangaf:

[...]


Dus op zich wel interessant om aan te geven wat je gebruikt en waarom. Neem tenminste aan dat niet iedereen blind hetzelfde heeft besteld als Femme.

Je kunt even de Topjobs catalogus van Wago downloaden. Dan zie je precies wat de verschillen zijn in de aansluitingen (hoe ze intern verbonden zijn bijv), welke spanning ze aankunnen etc en zie je ook wat er te koop is. Aard van dit soort spullen is wel dat enige voorkennis aangenomen wordt, of je huurt een installateur in. Vandaar zo weinig over te vinden. Catalogus vond ik zelf heel verhelderend in ieder geval.

[Rob Z]

Qua klemmen nog een voorbeeld van hier.
Dit is puur ter inspiratie, geen advies.

Wel een advies: gebruik kabelgoten van voldoende grootte (80 hoog). Ze zitten altijd sneller vol dan verwacht.

PTFIX blokjes van Phoenix verdelen de 230VAC naar de centraaldozen.
De schakeldraden voor verlichting (zwart, zwart/wit, grijs) zitten rechtstreeks op de relais.



De Gira pulsdrukkers voor de bediening zijn aangesloten met netwerkkabel (Belden 1583E massief).
De signalen zijn zonder tussenkomst van een klem op de ingangskaarten (links) aangesloten. De benodigde 24VDC komt wederom van een PTFIX klem.
Aanwezigheidssignalering gaat via Pananonic Papir sensoren (tip van Femme) die naar twee 5V ingangskaarten gaan.

[Fraggar]

Uit ervaring weet ik dat het prettig kan zijn om bepaalde zaken in huis te bedienen met een handbeweging. Ik gebruik nu de Fibaro Swipe, die kun je achter een schilderij of kastdeur plaatsen. Je zwaait dan met je hand langs de kastdeur en dimt daarmee bijvoorbeeld de verlichting. Maar dit is een z-wave product en ik zou liever een goedkoper alternatief hebben wat via de PLC loopt.

Zie bijvoorbeeld deze chip. Is het een moeilijke klus om zo'n soort chip aan de PLC te koppelen en de PLC via MQTT de opgevangen gebaren door te laten sturen?
@Verwijderd is dit iets wat je eventueel zou kunnen toevoegen aan jouw project?

[MewBie]

Fraggar schreef op zondag 12 april 2020 @ 23:20:
Uit ervaring weet ik dat het prettig kan zijn om bepaalde zaken in huis te bedienen met een handbeweging. Ik gebruik nu de Fibaro Swipe, die kun je achter een schilderij of kastdeur plaatsen. Je zwaait dan met je hand langs de kastdeur en dimt daarmee bijvoorbeeld de verlichting. Maar dit is een z-wave product en ik zou liever een goedkoper alternatief hebben wat via de PLC loopt.

Zie bijvoorbeeld deze chip. Is het een moeilijke klus om zo'n soort chip aan de PLC te koppelen en de PLC via MQTT de opgevangen gebaren door te laten sturen?
@Verwijderd is dit iets wat je eventueel zou kunnen toevoegen aan jouw project?

Sensor -> I2C -> Arduino of andere microcontroller -> hardwired -> PLC is waarschijnlijk de makkelijkste oplossing.

Code om de sensor uit te lezen staat zo te zien op de website, is dan dus een kwestie van waardes naar een output mappen.

[ Voor 7% gewijzigd door MewBie op 12-04-2020 23:50 ]

[Kanze]

Fraggar schreef op zondag 12 april 2020 @ 23:20:
Uit ervaring weet ik dat het prettig kan zijn om bepaalde zaken in huis te bedienen met een handbeweging. Ik gebruik nu de Fibaro Swipe, die kun je achter een schilderij of kastdeur plaatsen. Je zwaait dan met je hand langs de kastdeur en dimt daarmee bijvoorbeeld de verlichting. Maar dit is een z-wave product en ik zou liever een goedkoper alternatief hebben wat via de PLC loopt.

Zie bijvoorbeeld deze chip. Is het een moeilijke klus om zo'n soort chip aan de PLC te koppelen en de PLC via MQTT de opgevangen gebaren door te laten sturen?
@Verwijderd is dit iets wat je eventueel zou kunnen toevoegen aan jouw project?

Ik zie hier meteen toepassingen in de keuken voor. Aanzetten van vuren, dampkap, kranen... Mooie vondst @Fraggar

[Fraggar]

MewBie schreef op zondag 12 april 2020 @ 23:47:
[...]

Sensor -> I2C -> Arduino of andere microcontroller -> hardwired -> PLC is waarschijnlijk de makkelijkste oplossing.

Code om de sensor uit te lezen staat zo te zien op de website, is dan dus een kwestie van waardes naar een output mappen.

Is het echt noodzakelijk om er een microcontroller tussen te zetten, of zou zoiets ook rechtstreeks op de PLC kunnen mits je de juiste software hebt?

[Kanze]

Fraggar schreef op maandag 13 april 2020 @ 09:11:
[...]


Is het echt noodzakelijk om er een microcontroller tussen te zetten, of zou zoiets ook rechtstreeks op de PLC kunnen mits je de juiste software hebt?

I2C communicatie gaat niet direct op een PLC. Is bedoelt voor zeer korte afstanden op een PCB.

Je zal moeten interfacen met die sensor via een bijkomende chip. Ofwel laat je die chip de sensorwaardes beschikbaar maken via een serieel protocol ofwel laat je de chip signaal sturen naar de PLC maar dan heb je een dedicated line nodig naar een digital input

[MichVw]

Fraggar schreef op zondag 12 april 2020 @ 23:20:
Uit ervaring weet ik dat het prettig kan zijn om bepaalde zaken in huis te bedienen met een handbeweging. Ik gebruik nu de Fibaro Swipe, die kun je achter een schilderij of kastdeur plaatsen. Je zwaait dan met je hand langs de kastdeur en dimt daarmee bijvoorbeeld de verlichting. Maar dit is een z-wave product en ik zou liever een goedkoper alternatief hebben wat via de PLC loopt.

Zie bijvoorbeeld deze chip. Is het een moeilijke klus om zo'n soort chip aan de PLC te koppelen en de PLC via MQTT de opgevangen gebaren door te laten sturen?
@Verwijderd is dit iets wat je eventueel zou kunnen toevoegen aan jouw project?

Leuk ding die Fibaro Swipe
Met de PCB die we nu aan het ontwikkelen zijn zie ik het niet gebeuren, simpele reden is omdat de visie daar is om met Modbus polling te gaan werken wat volgens mij niet zal werken voor dergelijke 'events' vlot te capturen en er ogenblikkelijk een actie aan te koppelen. (Polling is nu eenmaal polling).

Idee met de PCB die onder ontwikkeling is is om zaken zoals temperatuur, luchtvochtigheid, luchtkwaliteit, stand regenput, etc.. binnen te lezen op de PLC via modbus RTU polling. Dat zijn waarden die niet gerelateerd zijn aan 'events' en zich dus ideaal lenen aan een polling mechanisme.

Als het echt over events gaat hebje andere keuzes:
1. rechtstreeks aansluiten op een digitale IO van de PLC (wat prijzig vind ik voor het aantal gebaren dat die gesture sensor aankan)
2. via een wired protocol op de TCP/IP stack werken en rechstreeks aansluiten op de PCB (zelf geen ervaring mee of interessante ervaringen om te delen hier)
3. binnenlezen via een MQTT subscriptie
4. via een automation een DO aansturen in de PLC (als je gebruik maakt van m'n project op git)

Die laatste twee zijn volgens mij hier meest van toepassing voor dergelijke gesture sensor. Gebruik maken van een ESP om de gesturen in MQTT publishes om te zetten lijkt me een mogelijke piste.

We zijn tweakers en we zullen altijd wel bezig zijn met iets en bedraden rechstreeks op de PLC zal zeker niet altijd lukken.. Dat is iets wat we voor ogen moeten zien

Niettemin is het mogelijk (via het project op git) om via een MQTT publish een DO aan te sturen op de PLC, dit scenario is iets waar ik gebruik zou maken van automations in HA/Node-Red en niet terugvallen op programmatie in de PLC.

Dat is natuurlijk slechts mijn mening, de keuze is aan jou

[Fraggar]

Nu ik begrijp dat het niet voor de hand ligt om de sensor rechtstreeks op de PLC aan te sluiten ben ik van plan om bijvoorbeeld met een Arduino te gaan werken. Deze zal dan rechtstreeks communiceren met de domotica controller.

Qua keuze voor de verwerking van de logica ben ik het met je eens. De PLC wordt in mijn situatie vooral een doorgeefluik richting de domotica controller.

[smaertens]

Hallo allemaal,

Het sluit niet helemaal aan bij het PLC gebeuren, dus excuses als de vraag niet op zijn plaats moest zijn.
Ik zal hier ook de gegevens van mijn Wago PLC doorsturen met MQTT naar een bovenliggend platform.(waarschijnlijk OpenHAB)
Daarnaast zou ik ook graag de waarden die mijn Fluvius digitale meter elke seconde uitspuwt op zijn P1 poort willen gaan visualiseren en gaan opslaan in een database.
Beetje zinloos om dat via de PLC te doen, ik dacht dat rechtstreeks op te sturen naar een klein programmatje op de domotica server dat de gegevens via IP binnenkrijgt en op zijn beurt over MQTT beschikbaar maakt.
Ik heb in het verleden veelvuldig gebruikt gemaakt van RS232 of RS485 naar IP converters (Moxa, Lantronics en dergelijke) om seriele data over een IP netwerk beschikbaar te zetten. Mijn digitale meter staat nameljik niet vlakbij het IT rack en er is ook niet meteen een stopcontact in de nabijheid.
Het ware natuurlijk mooi geweest als ik een converter kon gebruiken die via POE zijn voeding kon krijgen, en dat serieel signaal kon beschikbaar stellen in een TCP of UDP connectie. Jammer genoeg is de interface van de meter TTL en geen RS232.
Is er iemand die zoiets dergelijks gedaan heeft en die mij een duwtje in de richting kan geven welke hardware daarvoor in aanmerking komt? De seriele converters die ik ken werken niet met TTL of met USB ingangen.

[AUijtdehaag]

@smaertens Kun je niet iets doen met een raspberry pi en een poe hat?
Tesamen met dsmr reader en een p1 kabel?
Dat spuugt mqtt uit.

[ Voor 20% gewijzigd door AUijtdehaag op 16-04-2020 17:12 ]

[Kanze]

Arduino die TTL uitleest en via USB serial naar een USB-Ethernet IP converter stuurt?

[smaertens]

Hallo,

AUijtdehaag, Kanze Hartelijk dank voor jullie antwoord.

Inderdaad zulke zaken zie ik telkens opnieuw terug komen.
Ik stel mij dan toch de vraag of dat nu het meest practische / standaard oplossing is.
Ik kan mij maar niet ontdoen van het feit, dat wanneer de interface een RS485 of iets dergelijks was geweest dat dat het leven veel makkelijker had gemaakt. Ik zie waarschijnlijk iets over het hoofd.

Het bricoleren met printjes in plastieken behuizingskes , en customized firmware op sdk kaartjes kan beginnen .... net hetgeen ik hier wou voorkomen door een PLC te gebruiken met standaard protocols en proven technology ((sorry voor mijn toon, ik weet dat dat kort door de bocht is )

[AUijtdehaag]

@smaertens
Nou laat ons weten hoe het afloopt.
Ga ik weer verder met mijn plastieken rommel wat om de haverklap crashed.
(ik gebruik odroid n2 by the way)

[ Voor 26% gewijzigd door AUijtdehaag op 16-04-2020 19:07 ]

[Ethirty]

Ik snap sowieso die hele P1 poort niet. Iedereen moet zelf maar een product verzinnen om dit uit te lezen. Was dit nu echt de beste "standaard".

Maar goed, uitlezen en loggen lijkt me sowieso geen taak voor de PLC.

[Antonius]

aaahaaap schreef op zaterdag 28 maart 2020 @ 21:53:

<<knip>>

Kort door de bocht ben ik een "moderne" software development werkwijze gewend (dus sources in git, bouwen via CLI en automatisch deployen) en ditzelfde principe is ook een vereiste voor m'n home automation setup. Dit is iets dat erg ver af lijkt te staan van de software om PLCs mee te programmeren die ik tot nu toe heb gezien. Ik hoop dat ik hiermee niemand voor de schenen schop, maar het voelt allemaal een beetje als 10+ jaar geleden :x
Daarnaast draaien al m'n PCs op Linux en heb ik dus niks aan Windows only programma's. WINE is eventueel een optie maar de vraag is of dat goed werkt voor alle functionaliteit.
Op dit vlak lijkt een programmerbare controller (op basis van bijvoorbeeld Arduino) een stuk normaler/prettiger om mee te werken, je werkt aan je sources in je favoriete editor, commit ze, runt `make` of `platformio run` en je krijgt een gecompilde firmware voor op je controller.

Anyway, lang verhaal, om het conreet te maken, dit zijn de vragen die ik heb:
- Is het mogelijk op zo'n manier te werken met PLCs? Heeft iemand hier ervaring mee?
- Is er Linux compatible software om PLCs te programmeren?
- Zijn er CLI tools om de code voor de PLC te valideren en te uploaden naar de PLC?
- Heeft er iemand gekozen voor een microcontroller gebaseerd systeem ipv een PLC? Zo ja, hoe bevalt het? Of, als je daarna alsnog geswitcht bent naar een PLC, wat beviel er niet?

Deze vraag is al van een tijdje terug. De PLC wereld is inderdaad relatief behoudend. Ontwikkelingen lopen vaak een aantal jaar achter bij de "hippere" takken van software. Dat is duidelijk zichtbaar voor iemand die uit die andere wereld komt. Misschien is het wel nuttig voor je om te weten dat de Codesys ontwikkelomgeving vanaf versie 3.5 ondersteuning heeft voor python scripting. Hiermee kun je delen van het ontwikkel- en deploy proces automatiseren. Het is nog niet zeer wijdverbreid en de mogelijkheden worden nog steeds uitgebouwd, maar misschien heb je daar wel iets aan om dichter bij je eigen werkwijze te komen.

[Kanze]

smaertens schreef op donderdag 16 april 2020 @ 18:16:
Hallo,

AUijtdehaag, Kanze Hartelijk dank voor jullie antwoord.

Inderdaad zulke zaken zie ik telkens opnieuw terug komen.
Ik stel mij dan toch de vraag of dat nu het meest practische / standaard oplossing is.
Ik kan mij maar niet ontdoen van het feit, dat wanneer de interface een RS485 of iets dergelijks was geweest dat dat het leven veel makkelijker had gemaakt. Ik zie waarschijnlijk iets over het hoofd.

Het bricoleren met printjes in plastieken behuizingskes , en customized firmware op sdk kaartjes kan beginnen .... net hetgeen ik hier wou voorkomen door een PLC te gebruiken met standaard protocols en proven technology ((sorry voor mijn toon, ik weet dat dat kort door de bocht is )

Ethirty schreef op donderdag 16 april 2020 @ 18:53:
Ik snap sowieso die hele P1 poort niet. Iedereen moet zelf maar een product verzinnen om dit uit te lezen. Was dit nu echt de beste "standaard".

Maar goed, uitlezen en loggen lijkt me sowieso geen taak voor de PLC.

Naar wat ik begrepen heb heeft de overheid (in België) de opdracht gegeven aan Fluvius om een digitale meter in te voeren die "slim" is. Wat slim dan precies wil betekenen wordt niet gedefinieerd. Dus heeft men bij Fluvius dat opgenomen als zijnde dat de klant maar die slimme functionaliteit zelf moet implementeren. Waarschijnlijk heeft de fabrikant dan voorgesteld om het eenvoudigste serieel protocol te implementeren en dat is TTL.

Ik ben het eens dat dit niet onmiddellijk handig is. Misschien is het gebruik van een Raspberry Pi hier beter als een Arduino. Er bestaan POE hats dacht ik. Dan heb je het gehele embedded platform in 1 bakje en is het gewoon die TTL uitlezen en die data behapbaar maken voor je database met code op de RPI.

Dat bespaard toch al heel het gedoe met je eigen microchip gaan solderen enzo

[MewBie]

Kanze schreef op vrijdag 17 april 2020 @ 09:10:
[...]


[...]


Naar wat ik begrepen heb heeft de overheid (in België) de opdracht gegeven aan Fluvius om een digitale meter in te voeren die "slim" is. Wat slim dan precies wil betekenen wordt niet gedefinieerd. Dus heeft men bij Fluvius dat opgenomen als zijnde dat de klant maar die slimme functionaliteit zelf moet implementeren. Waarschijnlijk heeft de fabrikant dan voorgesteld om het eenvoudigste serieel protocol te implementeren en dat is TTL.

Ik ben het eens dat dit niet onmiddellijk handig is. Misschien is het gebruik van een Raspberry Pi hier beter als een Arduino. Er bestaan POE hats dacht ik. Dan heb je het gehele embedded platform in 1 bakje en is het gewoon die TTL uitlezen en die data behapbaar maken voor je database met code op de RPI.

Dat bespaard toch al heel het gedoe met je eigen microchip gaan solderen enzo

Het slimme gedeelte van een slimme meter is het op afstand uit kunnen lezen van de meterstand door de leverancier/netbeheerder.

En het zal me niks verbazen als de P1 poort oorspronkelijk bedoeld is voor gebruik door een monteur en niet voor gebruik met een automatiseringssysteem.

[Fraggar]

MewBie schreef op vrijdag 17 april 2020 @ 09:43:
En het zal me niks verbazen als de P1 poort oorspronkelijk bedoeld is voor gebruik door een monteur en niet voor gebruik met een automatiseringssysteem.

P0: Deze poort gebruikt de monteur om lokaal gegevens uit de meter te halen.

P1: Deze poort heet de gebruikersinterface. Door het aansluiten van daarvoor geschikte apparatuur, kunt u gedetail- leerde informatie over uw energieverbruik uit de meter halen. Er zijn energieverbruiksmanagers zoals apps of slimme thermostaten te koop die u kunt verbinden met de slimme meter, waardoor u continu inzicht heeft in uw energieverbruik.

Aldus de handleiding van mijn slimme meter. Ik lees hem via een RPi ieder uur uit en sla de standen dan op in een database.

[MichVw]

Fyi, ik heb zonet release 1.2 gemaakt van m'n domotica project voor Codesys 3.5:
https://github.com/Michie...omation.CoDeSys3/releases

De klemtoon ligt op RS485, voor het moment is er maar één device FB en dat is om een Eastron SDM220 uit te lezen. Nieuwe FB's kunnen echter met minimale moeite toegevoegd worden (maak gerust een issue aan als je hulp nodig hebt)

De RS485 implementatie werkt met zowel é!cockpit als codesys 3S, daar is ook het grotendeel van het werk ingekropen. Veel werk dus een sterretje word nog altijd gewaardeerd

Dit zal waarschijnlijk de laatste 'grotere' release worden voor even daar m'n aandacht nu shift naar het ontwikkelen van een RS485 PCB die overal ingewerkt kan worden en uitgelezen door de PLC. Het Prototype is gisteren getest en goed bevonden. Ik plaats een update hier met een link naar de git repo eenmaal de v1 af is.

Ik begrijk dat niet iedereen te vinden is voor zo'n custom PCB en heb ook geen idee of het mogelijk zal zijn om ze ergens te bestellen zodat er geen soldeerwerk meer aan is (aan betaalbare prijs). Niettemin geloof ik toch dat het voor veel mensen een toegevoegde waarde kan zijn om via een extra PCB eender welke sensor te kunnen binnenlezen rechstreeks op hun PLC.

[Kobus Post]

Zit nu even webinar van Schneider Electric mee te kijken, maar die Hebben een nieuwe plc (de M262) met MQTT & JSON native ingebouwd.

Wat ik er van zie krijgen de M241 & M251 ook MQTT support, maar geen SSL (dat heeft de M262 wel).

[THM0]

@Michvw voor jullie PCB project: wellicht is dit nog interessant: https://knx-user-forum.de...res-voc-co2-1-wire-buzzer
In Duitsland zijn ze met iets soortgelijks bezig, maar dan obv KNX.

[Rob Z]

MichVw schreef op vrijdag 17 april 2020 @ 13:06:
[...]
De klemtoon ligt op RS485
[...]

...wat later ingestapt hier, maar Modbus RTU is van toepassing?

[Kanze]

Rob Z schreef op dinsdag 21 april 2020 @ 16:26:
[...]

...wat later ingestapt hier, maar Modbus RTU is van toepassing?

MOBUS RTU is layer 3 en gebruikte RS485 als layer 2

[Fraggar]

Kan iemand me uitleggen waar codeerelementen voor gebruikt worden?
Zoals deze: https://www.wago.com/nl/t...enten-serie-753/p/753-150

En kun je die gebruiken i.c.m. deze module?
https://www.wago.com/glob...l-digital-input/p/753-434

[ Voor 50% gewijzigd door Fraggar op 03-05-2020 14:12 ]

[Rob Z]

@Fraggar ik vermoed dat ze zijn bedoeld om I/O kaarten fysiek te coderen zodat er een connector op past met een overeenkomstige codering. Het doel is onbedoelde verwisseling van connectoren te voorkomen.

[THM0]

Fraggar schreef op zondag 3 mei 2020 @ 13:46:
Kan iemand me uitleggen waar codeerelementen voor gebruikt worden?
Zoals deze: https://www.wago.com/nl/t...enten-serie-753/p/753-150

En kun je die gebruiken i.c.m. deze module?
https://www.wago.com/glob...l-digital-input/p/753-434

Volgens mij voor oa de 753 serie modules. Die hebben een soort los element wat je erbovenop klikt.
Ik heb een 753-646 (KNX interface), in de handleiding hebben ze het over die plugjes die je noemt. DIe zitten dan tussen de module en dat opzetelement.

[ Voor 5% gewijzigd door THM0 op 03-05-2020 21:33 ]

[Fraggar]

THM0 schreef op zondag 3 mei 2020 @ 21:33:
[...]

Volgens mij voor oa de 753 serie modules. Die hebben een soort los element wat je erbovenop klikt.
Ik heb een 753-646 (KNX interface), in de handleiding hebben ze het over die plugjes die je noemt. DIe zitten dan tussen de module en dat opzetelement.

Ja volgens mij klopt het wat je zegt. Ik zie ze ook zitten in dit plaatje. Maar ik begrijp nog niet waarom ze er tussen kunnen/moeten zitten.

In het opzetstuk zie ik ook twee rode puntjes afgebeeld. Dat lijken dan ook weer extra codeerelementen?

Ik heb de module momenteel in gebruik zonder alle rode codeerelementen.

[BlackShadow]

Sinds een tijdje merk ik dat modbus traag reageert in Home Assistant.
Dit was vroeger niet, aan de PLC's is niets gewijzigd, Home Assistant werd intussen wel reeds verschillende keren geupdate.

Ik zie volgende meldingen continu verschijnen in de logs:
2020-05-04 11:02:29 WARNING (MainThread) [homeassistant.components.switch] Updating modbus switch took longer than the scheduled update interval 0:00:01

Ik heb al verschillende malen gezocht naar soortgelijke meldingen, maar aangezien MODBUS niet zo populair is, vind ik niemand met een gelijkaardig probleem.

Ik gebruik het script van @MichVw waarbij de PLC MQTT verstuurt afhankelijk van de input, uitgangen lees en schrijf ik via MODBUS.

Iemand een idee?

[THM0]

Fraggar schreef op zondag 3 mei 2020 @ 22:10:
[...]


Ja volgens mij klopt het wat je zegt. Ik zie ze ook zitten in dit plaatje. Maar ik begrijp nog niet waarom ze er tussen kunnen/moeten zitten.

In het opzetstuk zie ik ook twee rode puntjes afgebeeld. Dat lijken dan ook weer extra codeerelementen?

Ik heb de module momenteel in gebruik zonder alle rode codeerelementen.

[Afbeelding]

Even zitten zoeken, het zijn coding fingers, als je goed kijkt op het plaatje zie je kleine pijltjes die aan de bovenzijde van de module zichtbaar zijn. Die kunnen ieder op 4 manieren staan, dus met twee van die elementen kun je 16 combinaties maken en dus op de module een configuratie oid communiceren/vastleggen. Net zoiets als WSB markers. Het heeft verder geen functie in de software.

[MichVw]

BlackShadow schreef op maandag 4 mei 2020 @ 11:06:
Sinds een tijdje merk ik dat modbus traag reageert in Home Assistant.
Dit was vroeger niet, aan de PLC's is niets gewijzigd, Home Assistant werd intussen wel reeds verschillende keren geupdate.

Ik zie volgende meldingen continu verschijnen in de logs:
2020-05-04 11:02:29 WARNING (MainThread) [homeassistant.components.switch] Updating modbus switch took longer than the scheduled update interval 0:00:01

Ik heb al verschillende malen gezocht naar soortgelijke meldingen, maar aangezien MODBUS niet zo populair is, vind ik niemand met een gelijkaardig probleem.

Ik gebruik het script van @MichVw waarbij de PLC MQTT verstuurt afhankelijk van de input, uitgangen lees en schrijf ik via MODBUS.

Iemand een idee?

Codesys 3.5? Gebruik anders gewoon de output FB om de uitgangen aan te sturen via MQTT ipv Modbus?
https://github.com/Michie.../FB_OUTPUT_SWITCH_MQTT.md

[BlackShadow]

MichVw schreef op maandag 4 mei 2020 @ 13:26:
[...]


Codesys 3.5? Gebruik anders gewoon de output FB om de uitgangen aan te sturen via MQTT ipv Modbus?
https://github.com/Michie.../FB_OUTPUT_SWITCH_MQTT.md

Hmm, begrijp ik het goed dat ik via MQTT de uitgangen kan aansturen, dus dat een Wago 750-881 MQTT subscribe ondersteunt?
De versie die momenteel op de controllers staat, is gemaakt met Codesys V2.3

Heb even geinformeerd voor een update naar V3.5, maar daarvoor heb ik licenties van e!COCKPIT nodig zo blijkt...

[MichVw]

BlackShadow schreef op maandag 4 mei 2020 @ 15:02:
[...]


Hmm, begrijp ik het goed dat ik via MQTT de uitgangen kan aansturen, dus dat een Wago 750-881 MQTT subscribe ondersteunt?
De versie die momenteel op de controllers staat, is gemaakt met Codesys V2.3

Heb even geinformeerd voor een update naar V3.5, maar daarvoor heb ik licenties van e!COCKPIT nodig zo blijkt...

Wago 750-881 is Codesys v2.3 enkel dus geen MQTT subscribe...
Ik heb toevallig een PFC200 die ik verkoop (kan wel Codesys 3.5 aan), mocht je interesse hebben;
V&A aangeboden: Wago PFC200 - Codesys 3.5 only

[BlackShadow]

MichVw schreef op maandag 4 mei 2020 @ 15:29:
[...]


Wago 750-881 is Codesys v2.3 enkel dus geen MQTT subscribe...
Ik heb toevallig een PFC200 die ik verkoop (kan wel Codesys 3.5 aan), mocht je interesse hebben;
V&A aangeboden: Wago PFC200 - Codesys 3.5 only

Ik heb momenteel 3 750-881 PLCs in gebruik, deze hiervoor vervangen is momenteel niet aan de orde.

Mocht iemand een idee hebben waar die vertraging ontstaat, dan hoor ik het graag.
Mijn vermoeden is dat het aan Home Assistant ligt, het probleem is na een migratie naar een andere server ontstaan.

[MichVw]

BlackShadow schreef op maandag 4 mei 2020 @ 15:35:
[...]


Ik heb momenteel 3 750-881 PLCs in gebruik, deze hiervoor vervangen is momenteel niet aan de orde.

Mocht iemand een idee hebben waar die vertraging ontstaat, dan hoor ik het graag.
Mijn vermoeden is dat het aan Home Assistant ligt, het probleem is na een migratie naar een andere server ontstaan.

drie stuks, kan ik begrijpen eventeel kan je eens onderzoeken of je met Home Assistant custom TCP messages kan sturen. Ik heb lang geleden iets geschreven in Codesys 2.3 dat custom TCP messages uitlas en er een output mee schakelde. (het was enkel een POC en ik vond het wat omslachtig en niet echt dynamisch om mee te werken zoals MQTT maar als je interesse hebt kan ik het project nog eens zoeken)

[smaertens]

BlackShadow schreef op maandag 4 mei 2020 @ 15:35:
[...]


Ik heb momenteel 3 750-881 PLCs in gebruik, deze hiervoor vervangen is momenteel niet aan de orde.

Mocht iemand een idee hebben waar die vertraging ontstaat, dan hoor ik het graag.
Mijn vermoeden is dat het aan Home Assistant ligt, het probleem is na een migratie naar een andere server ontstaan.

De manier waarop ik dit zou debuggen

Tracht op de PC waar HomeAssitance op draait een wireshark (of desnoods Tshark) traffic sniff te doen.
Modbus is een polling protocol. Je home assistance zal dus 1 voor 1 de registers gaan pollen en (blijkbaar voor HA) te laat een return krijgen.
Ofwel reageert de PLC te traag (kan je zien in de traffic capture). Ofwel reageert hij snel genoeg en is het ergens in home assistance dat het inkomende packet niet of verkeerd behandeld werd. Misschien is er zelfs ergens een timeout variabele die je kan configureren op HA.

Als ik het goed begrijp schrijf je een modbus register van een bepaalde output. Daarna tracht je met modbus een register in te lezen dat de status van die output weergeeft.
Je kan eenvoudig zien in wireshark/tshark wat de juiste modbus commando's zijn en de response erop. Er zijn standaard dissectors voor modbus.

[MichVw]

smaertens schreef op dinsdag 5 mei 2020 @ 13:38:
[...]


De manier waarop ik dit zou debuggen

Tracht op de PC waar HomeAssitance op draait een wireshark (of desnoods Tshark) traffic sniff te doen.
Modbus is een polling protocol. Je home assistance zal dus 1 voor 1 de registers gaan pollen en (blijkbaar voor HA) te laat een return krijgen.
Ofwel reageert de PLC te traag (kan je zien in de traffic capture). Ofwel reageert hij snel genoeg en is het ergens in home assistance dat het inkomende packet niet of verkeerd behandeld werd. Misschien is er zelfs ergens een timeout variabele die je kan configureren op HA.

Als ik het goed begrijp schrijf je een modbus register van een bepaalde output. Daarna tracht je met modbus een register in te lezen dat de status van die output weergeeft.
Je kan eenvoudig zien in wireshark/tshark wat de juiste modbus commando's zijn en de response erop. Er zijn standaard dissectors voor modbus.

goeie tips, dit kan eventueel ook een hulp zijn:
https://github.com/Michie.../RS485_tips_and_tricks.md

[smaertens]

MichVw schreef op dinsdag 5 mei 2020 @ 15:22:
[...]


goeie tips, dit kan eventueel ook een hulp zijn:
https://github.com/Michie.../RS485_tips_and_tricks.md

Ik ging er wel vanuit dat het Modbus TCP was

[MichVw]

smaertens schreef op dinsdag 5 mei 2020 @ 17:42:
[...]


Ik ging er wel vanuit dat het Modbus TCP was

Uhum, goed punt

[Fraggar]

Kanze schreef op donderdag 9 april 2020 @ 14:46:
[...]


Klopt wat je zegt hoor! Het ontwerpen van die eigen sensors is vooral gemotiveerd door eigen interesse en motivatie. In een dergelijke situatie kijk je niet naar geïnvesteerde tijd als een kost maar als een hobby besteding. Zoiets doe je dus inderdaad niet als het je gewoon te doen is om iets werkende te krijgen.

Dat gezegd zijnde wil ik altijd meedenken aan andere opstellingen en oplossingen. In het geval van een 1-Wire netwerk zou je kunnen werken met een 1-Wire controller van Esera via RS232 of Ethernet.

In de specsheets van die controllers staat wel een lijst met supported chips. Dus nu weet ik niet of die controller ook direct met dat PCB'tje uit je post kan praten?

Ik kan niet goed vinden of de Esera 1-wire controller over ethernet ook makkelijk gekoppeld kan worden met verschillende home automation servers. In de uitleg over de integratie met de Loxone miniserver wordt er gesproken over data versturen over tcp/udp, maar het is me niet duidelijk of dit ook eenvoudig te ontvangen/interpreteren is voor andere domotica-oplossingen. Heeft iemand hier ervaring mee?

Als alternatief kwam ik de OW-SERVER tegen. Dit apparaat kan 22 1-wire-apparaten uitlezen en de data via HTTP Post naar een URL versturen. Lijkt me eenvoudig te integreren met andere domotica-oplossingen. Heeft iemand ervaring met dit product?

[Ethirty]

Je hebt van Esera een Gateway en een Controller.
Controllers kunnen Modbus doen, de Gateway doet iets van plain text op je netwerk gooien.

De website heeft wat dode links, maar ik zie deze comment:
Läuft wunderbar via UDP Socket mit IP Symcon.

Ik zou kijken of je niet beter een Controller met Modbus kan doen als je iets kant en klaars wil.

[roller12358]

---never mind---

[ Voor 98% gewijzigd door roller12358 op 09-05-2020 00:28 ]

[roller12358]

[ Voor 99% gewijzigd door roller12358 op 09-05-2020 00:33 ]

[Ethirty]

Huh, je schreef toch wat over Logo? Hoezo haal je dat nu weg?

[roller12358]

Ethirty schreef op zaterdag 9 mei 2020 @ 11:19:
Huh, je schreef toch wat over Logo? Hoezo haal je dat nu weg?

Klopt. Het was een reactie op een oude post. Ik zag dat mijn reactie pas hier helemaal onderaan terecht kwam waardoor het eigenlijk nergens meer op sloeg.

[Ethirty]

roller12358 schreef op zaterdag 9 mei 2020 @ 12:10:
[...]


Klopt. Het was een reactie op een oude post. Ik zag dat mijn reactie pas hier helemaal onderaan terecht kwam waardoor het eigenlijk nergens meer op sloeg.

Als je de oorspronkelijke post quote is het prima te volgen toch. Ben in ieder geval blij dat ik gisteravond nog even op je linkje heb kunnen klikken.

[roller12358]

Ethirty schreef op zaterdag 9 mei 2020 @ 12:49:
[...]

Als je de oorspronkelijke post quote is het prima te volgen toch. Ben in ieder geval blij dat ik gisteravond nog even op je linkje heb kunnen klikken.

Hier nog een keer de post. Het was een reactie op een heel oud bericht maar de kern staat in de Quote.

MewBie schreef op woensdag 26 februari 2020 @ 21:52:
[...]

Zo te zien ondersteunen de Logo's modbus tcp als ze een ethernet port hebben.

Ja de LOGO! 7 en 8 bevat een ethernetpoort en kan commando's ontvangen en verzenden via netwerk. De ingebouwde webserver kon ik niet zoveel mee, toch heb ik er wel eens een projectje mee gedaan. Draait al 4 jaar probleemloos met domoticz. De Raspberry Pi 3 waarop Domoticz en Logocontrol draait heb ik 1x moeten herstarten na een bepaalde update van Linux. Het systeem wordt dagelijks gebruikt voor schakelen van verlichting en rolluiken, bijhouden opbrengst zonnepanelen en uitlezen van sensoren.

Meer info over een REST koppeling tussen de LOGO en een domoticasysteem is te vinden op: http://www.frickelzeugs.de/logocontrol/.

Schematisch:

LOGO!7 <---> logocontrol REST API <---> Domoticz

De beschreven REST API kan dus vanuit bv. domoticz aangestuurd (of uitgelezen) worden. Voorbeeldje: schakel buitenlamp in wordt zoiets als

code:

curl -ipv4 http://localhost:8088/rest/devices/100/methods/1

Vanuit Logocontrol kun je ook Domoticz aansturen. Lamp aan wordt dan bv

code:

https://IPadres:443/json.htm?type=command&param=switchlight&idx=10&switchcmd=On

Inmiddels is er wel veel gebeurd, zowel Linux als Domoticz zijn een aantal keren geupdate. Ik heb nog niet kunnen testen of de nieuwste Domoticz, nieuwe Raspbian en actuele versies van Mono en Libnodave samenwerkt met de beschikbare Logocontrol software. Logocontrol is door de programmeur 4 jaar geleden voor het laatst bijgewerkt...

Helaas heb ik nog geen andere werkende manier gezien tot nu toe.

[jphermans]

Ik heb logocontrol draaien in een docker container op een synology nas met een 64bit processor en dit draait heel goed. Hierbij maak ik dan ook sinds kort ook gebruik van node-red en dit werkt ook goed maar moet alleen nog javascript leren om alles wat beter te regelen en te visualeren in het node-red dashboard.

[THM0]

Nieuwe PFC200 firmware: https://github.com/WAGO/pfc-firmware/releases/tag/v03.04.10

[drled]

De meeste kiezen hier duidelijk voor de PFC200 als controller, echter is de PFC100 een stuk goedkoper, zijn er grote nadelen?

[ Voor 15% gewijzigd door drled op 14-05-2020 13:25 ]

[THM0]

drled schreef op donderdag 14 mei 2020 @ 13:24:
De meeste kiezen hier duidelijk voor de PFC200 als controller, echter is de PFC100 een stuk goedkoper, zijn er grote nadelen?

Nee voor domotica kun je met een PFC100 prima uit de voeten lijkt me. Programma geheugen is iets kleiner, maar voor een normale woning kan ik me nauwelijks voorstellen dat dat een praktisch probleem oplevert.
Als je per se een e!Cockpit licentie wilt dan is die in een starterkit te krijgen met een PFC100, terwijl dat voor een PFC200 niet het geval is.

Ikzelf heb mijn PFC200's van eBay, als je dat een beetje in de gaten houdt maakt het qua kosten niet zoveel tov een PFC100.

[MichVw]

drled schreef op donderdag 14 mei 2020 @ 13:24:
De meeste kiezen hier duidelijk voor de PFC200 als controller, echter is de PFC100 een stuk goedkoper, zijn er grote nadelen?

Klopt, op Ebay kan je echte koopjes doen. Ook de onboard RS485 poort kan handig zijn. Je kan er bv eastron SDM energiemeters mee uitlezen

[Fraggar]

@MichVw Ik ben bezig met het testen van de Panasonic AMN31112J. Als ik de output meet zie ik dat deze bij beweging hoog wordt, maar al zeer snel weer laag wordt en zelfs wat hoog/laag knippert bij overgangssituaties.

Om te voorkomen dat er onnodig veel verkeer plaatsvindt tussen de PLC en de domotica-software wil ik dit gedrag afvangen in de PLC door bijvoorbeeld de volgende regels te stellen die impact hebben op de events die middels MQTT worden gepublished:

• Er wordt hoog gedetecteerd: MQTT: Motion
• Als er 5 seconden lang laag wordt gedetecteerd na hoog, is het laag: MQTT: No Motion

FB_INPUT_PUSHBUTTON_MQTT kan ik hiervoor niet gebruiken omdat er dan een single, double of zelfs een long input wordt gedetecteerd.
FB_INPUT_BINARYSENSOR_MQTT genereert verkeer bij elke statusverandering, bij deze bewegingssensor resulteert dat dan in veel verkeer.

Zou je een basic function block kunnen ontwerpen dat geschikt is voor een bewegingssensor? Waarbij bijvoorbeeld een parameter in te stellen is na hoeveel seconden laag het weer als laag wordt aangemerkt?

[MichVw]

Fraggar schreef op vrijdag 15 mei 2020 @ 11:18:
@MichVw Ik ben bezig met het testen van de Panasonic AMN31112J. Als ik de output meet zie ik dat deze bij beweging hoog wordt, maar al zeer snel weer laag wordt en zelfs wat hoog/laag knippert bij overgangssituaties.

Om te voorkomen dat er onnodig veel verkeer plaatsvindt tussen de PLC en de domotica-software wil ik dit gedrag afvangen in de PLC door bijvoorbeeld de volgende regels te stellen die impact hebben op de events die middels MQTT worden gepublished:

• Er wordt hoog gedetecteerd: MQTT: Motion
• Als er 5 seconden lang laag wordt gedetecteerd na hoog, is het laag: MQTT: No Motion

FB_INPUT_PUSHBUTTON_MQTT kan ik hiervoor niet gebruiken omdat er dan een single, double of zelfs een long input wordt gedetecteerd.
FB_INPUT_BINARYSENSOR_MQTT genereert verkeer bij elke statusverandering, bij deze bewegingssensor resulteert dat dan in veel verkeer.

Zou je een basic function block kunnen ontwerpen dat geschikt is voor een bewegingssensor? Waarbij bijvoorbeeld een parameter in te stellen is na hoeveel seconden laag het weer als laag wordt aangemerkt?

Een hysteresis lus dus met andere woorden ja, lijkt me een goed idee, ik kijk ervoor! (maak gerust ook een issue aan op de git repo)

[drled]

In afwachting van een goeie deal op ebay(pfc200), ben ik ook opzoek naar een geschikte Stuurkast/zekeringkast om alles in kwijt te krijgen.

Iemand aanraders voor een betaalbare kast?
Had reeds de Schrack Modul160 gekocht, maar de hoogte vanop de din-rail is te klein(slechts 51mm) voor montage van bv. een PFC200.

[Rob Z]

Fraggar schreef op vrijdag 15 mei 2020 @ 11:18:
@MichVw Ik ben bezig met het testen van de Panasonic AMN31112J. Als ik de output meet zie ik dat deze bij beweging hoog wordt, maar al zeer snel weer laag wordt en zelfs wat hoog/laag knippert bij overgangssituaties.
[...]

Ze zijn (logischerwijs) zeer gevoelig. Het advies is een pull down weerstand te gebruiken op het signaal.

[yniezink]

@MichVw Gisteren je software op de PLC kunnen zetten en die draait nu als een zonnetje.

Ik loop echter nog wel tegen problemen aan. Het gaat hier dan het integreren met Home Assistant en vermoed dat het iets te maken heeft met de verwerking van de MQTT berichten.

ik heb https://github.com/Michie.../FB_OUTPUT_SWITCH_MQTT.md uitgebreid doorgenomen en heb zo ook de code juist gevuld.

Echter gebeurd er niks als er een waarde naar command_topic: "WAGO-PFC200/In/DigitalOutputs/FB_DO_SW_001 wordt geschreven. De PLC doet er niets mee en de status veranderd dus ook niet.

In PLC_PRG_main.MAIN_INIT heb ik staan:

code:

(* INIT DIGITAL OUTPUT STUFF *)
FB_DO_SW_001.InitMQTT(MQTTPublishPrefix:= ADR(MQTTPubSwitchPrefix),                 (* pointer to string prefix for the MQTT publish topic *)
    MQTTSubscribePrefix:= ADR(MQTTSubSwitchPrefix),                                 (* pointer to string prefix for the MQTT subscribe topic *)
    pMQTTPublishQueue := ADR(MQTTVariables.fbMQTTPublishQueue),                     (* pointer to MQTTPublishQueue to send a new MQTT event *)
    pMQTTCallbackCollector := ADR(MQTTVariables.collector_FB_OUTPUT_SWITCH_MQTT)    (* pointer to CallbackCollector to receive MQTT subscription events *)
);

in PLC_PRG_MAIN heb ik:

code:

    (* OUTPUT FUNCTION BLOCKS *)
    MqttPubSwitchPrefix         :STRING(100) := 'WAGO-PFC200/Out/DigitalOutputs/';
    MqttSubSwitchPrefix         :STRING(100) := 'WAGO-PFC200/In/DigitalOutputs/';
    FB_DO_SW_001                :FB_OUTPUT_SWITCH_MQTT;

en in PLC_PRG_MAIN.WRITE_SWITCHES

code:

FB_DO_SW_001(OUT    =>      DO_001,                                     (* couple the function block to the physical output *)
    PRIO_HIGH               :=FALSE,                                    (* brings the output high regardless of other input values *)
    PRIO_LOW                :=FALSE,                                    (* brings the output low regardless of other input values. NOTE: PRIO_HIGH overrules PRIO_LOW input *)
    TOGGLE                  :=FB_DI_PB_001.SINGLE                       (* for toggling the output *)   
);

Volgens mij heb ik exact gedaan wat beschreven staat op de pagina. Of zie ik iets over het hoofd?

Uiteraard heb ik wel getest of er een goede verbinding is met de MQTT server, en dat is er. Voor de code in Home Assistant heb ik ook gewoon het voorbeeld gebruikt van Switch 1

[MichVw]

yniezink schreef op dinsdag 26 mei 2020 @ 07:15:
@MichVw Gisteren je software op de PLC kunnen zetten en die draait nu als een zonnetje.

Ik loop echter nog wel tegen problemen aan. Het gaat hier dan het integreren met Home Assistant en vermoed dat het iets te maken heeft met de verwerking van de MQTT berichten.

ik heb https://github.com/Michie.../FB_OUTPUT_SWITCH_MQTT.md uitgebreid doorgenomen en heb zo ook de code juist gevuld.

Echter gebeurd er niks als er een waarde naar command_topic: "WAGO-PFC200/In/DigitalOutputs/FB_DO_SW_001 wordt geschreven. De PLC doet er niets mee en de status veranderd dus ook niet.

In PLC_PRG_main.MAIN_INIT heb ik staan:

code:

(* INIT DIGITAL OUTPUT STUFF *)
FB_DO_SW_001.InitMQTT(MQTTPublishPrefix:= ADR(MQTTPubSwitchPrefix),                 (* pointer to string prefix for the MQTT publish topic *)
    MQTTSubscribePrefix:= ADR(MQTTSubSwitchPrefix),                                 (* pointer to string prefix for the MQTT subscribe topic *)
    pMQTTPublishQueue := ADR(MQTTVariables.fbMQTTPublishQueue),                     (* pointer to MQTTPublishQueue to send a new MQTT event *)
    pMQTTCallbackCollector := ADR(MQTTVariables.collector_FB_OUTPUT_SWITCH_MQTT)    (* pointer to CallbackCollector to receive MQTT subscription events *)
);

in PLC_PRG_MAIN heb ik:

code:

    (* OUTPUT FUNCTION BLOCKS *)
    MqttPubSwitchPrefix         :STRING(100) := 'WAGO-PFC200/Out/DigitalOutputs/';
    MqttSubSwitchPrefix         :STRING(100) := 'WAGO-PFC200/In/DigitalOutputs/';
    FB_DO_SW_001                :FB_OUTPUT_SWITCH_MQTT;

en in PLC_PRG_MAIN.WRITE_SWITCHES

code:

FB_DO_SW_001(OUT    =>      DO_001,                                     (* couple the function block to the physical output *)
    PRIO_HIGH               :=FALSE,                                    (* brings the output high regardless of other input values *)
    PRIO_LOW                :=FALSE,                                    (* brings the output low regardless of other input values. NOTE: PRIO_HIGH overrules PRIO_LOW input *)
    TOGGLE                  :=FB_DI_PB_001.SINGLE                       (* for toggling the output *)   
);

Volgens mij heb ik exact gedaan wat beschreven staat op de pagina. Of zie ik iets over het hoofd?

Uiteraard heb ik wel getest of er een goede verbinding is met de MQTT server, en dat is er. Voor de code in Home Assistant heb ik ook gewoon het voorbeeld gebruikt van Switch 1

goed om te horen dat je het vlot werkend gekregen hebt.
Voor je MQTT probleem:
- krijg je de hartbeat berichten van de PLC?
- is de MQTT task enabled op de PLC?

[yniezink]

MichVw schreef op dinsdag 26 mei 2020 @ 08:14:
[...]


goed om te horen dat je het vlot werkend gekregen hebt.
Voor je MQTT probleem:
- krijg je de hartbeat berichten van de PLC?
- is de MQTT task enabled op de PLC?

Ik kreeg de heartbeat berichten. Devices/WAGO-PFC200/availability gaf ook netjes status online.

De MQTT task staat op prioriteit 5, en type freewheeling. De watchdog is niet enabled.

Nu gaat het echter weer niet helemaal lekker. Zie in Mosquitto dat de PLC netjes verbind na een reset. Echter nu is de status offline.

[MichVw]

yniezink schreef op dinsdag 26 mei 2020 @ 08:44:
[...]


Ik kreeg de heartbeat berichten. Devices/WAGO-PFC200/availability gaf ook netjes status online.

De MQTT task staat op prioriteit 5, en type freewheeling. De watchdog is niet enabled.

Nu gaat het echter weer niet helemaal lekker. Zie in Mosquitto dat de PLC netjes verbind na een reset. Echter nu is de status offline.

vreemd, kan je de PLC nog pingen? welke runtime gebruik je? é!cockpit of codesys?
de MQTT lib heeft ook een 'errorhistory' object waar je eens kan gaan kijken:
https://github.com/stefan.../integration.md#debugging

Eventueel zijn er connectie problemen naar de broker?

[yniezink]

MichVw schreef op dinsdag 26 mei 2020 @ 08:50:
[...]


vreemd, kan je de PLC nog pingen? welke runtime gebruik je? é!cockpit of codesys?
de MQTT lib heeft ook een 'errorhistory' object waar je eens kan gaan kijken:
https://github.com/stefan.../integration.md#debugging

Eventueel zijn er connectie problemen naar de broker?

Ik maak gebruik van E!cockpit. Pingen werkt gewoon.

Net de het programma opnieuw gestart. ik krijg een melding op mosquitto dat er zich een nieuwe client heeft aangemeld (de PLC).

Echter kijk ik dan op het availability topic zie ik onderstaande:

code:

Bericht 0 ontvangen op Devices/WAGO-PFC200/availability om 8:52 :
offline

Het is net of de verbinding gemaakt wordt en dan wordt afgebroken. Ik zal eens kijken of ik er uit kan komen en die logs kan vinden.

En anders download ik je project opnieuw en begin ik dus ook weer opnieuw. Maar dacht dat ik niks geks had gedaan. Het fysieke schakelen met de pushbuttons werkt wel normaal

Edit
Ben opnieuw begonnen, nu gaat schakelen via MQTT wel goed, maar zodra ik met de hand de pulsedrukker in druk dan lijkt het erop dat er iets vastloopt. bedienen via MQTT werkt dan niet meer. Controle via de pulsedrukker blijft werken.

Aanzetten via pulsdrukker en uit via Home Assistant werkt dus bijvoorbeeld niet

[ Voor 21% gewijzigd door yniezink op 26-05-2020 10:18 ]

[MichVw]

yniezink schreef op dinsdag 26 mei 2020 @ 08:54:
[...]


Ik maak gebruik van E!cockpit. Pingen werkt gewoon.

Net de het programma opnieuw gestart. ik krijg een melding op mosquitto dat er zich een nieuwe client heeft aangemeld (de PLC).

Echter kijk ik dan op het availability topic zie ik onderstaande:

code:

Bericht 0 ontvangen op Devices/WAGO-PFC200/availability om 8:52 :
offline

Het is net of de verbinding gemaakt wordt en dan wordt afgebroken. Ik zal eens kijken of ik er uit kan komen en die logs kan vinden.

En anders download ik je project opnieuw en begin ik dus ook weer opnieuw. Maar dacht dat ik niks geks had gedaan. Het fysieke schakelen met de pushbuttons werkt wel normaal

Edit
Ben opnieuw begonnen, nu gaat schakelen via MQTT wel goed, maar zodra ik met de hand de pulsedrukker in druk dan lijkt het erop dat er iets vastloopt. bedienen via MQTT werkt dan niet meer. Controle via de pulsedrukker blijft werken.

Aanzetten via pulsdrukker en uit via Home Assistant werkt dus bijvoorbeeld niet

vreemd, maar deels zeker ook positief dat de core logica blijft werken. Het is tenslotte de bedoeling dat andere huisgenoten nog het licht kunnen aansteken als de tweaker in ons iets verprutst

al iets gevonden in de errorlogs aangegeven in de link in m'n vorige comment?