Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

Domotica met plc's

Pagina: 1 ... 8 ... 11 Laatste
Acties:

Onderwerpen


  • thomke
  • Registratie: november 2011
  • Laatst online: 02-04 20:05
nYzEkE schreef op donderdag 26 september 2019 @ 14:32:
Ik zal deze topic ook maar eens toevoegen, ik heb zelf in mijn huis ook een plc, S7-300 van siemens.
Waar nu de lichtsturing en verwarming op gekoppeld zit.
De bedoeling is dat mijn stroomverbruik en zonnepanelen ook gekoppeld worden.

Voor dit alles zoek ik nog een mooi scada pakketje. Geen idee wat ik daarvoor zal gebruiken.

Ik heb nog heel wat werk om de kast eens een beetje op te ruimen. Maar bij deze toch een fototje

[Afbeelding]
even ter info, maar PLC's (zeker die van siemens) en ik denk eigenlijk dat dit voor de meeste pasieve gekoelde toestellen is.. worden best horizontaal gemonteerd.. staat ook in de manual van het toestel, dat bij verkeerde montage (dus indien niet horizontaal) de garantie vervalt...

  • nYzEkE
  • Registratie: augustus 2008
  • Laatst online: 04-04 20:04
Och, geen zorgen garantie heb ik al lang niet meer op die onderdelen. Het zijn afbraak onderdelen, en ik versta wel voor natuurlijke ventilatie, maar in een koude ruimte (koele berging) zie ik niet direct een probleem voor mijn toepassing

Edit: net even opgezocht
https://i.imgur.com/qRG80GG.png
Het is dus zo dat horizontaal een omgeving tot 60°C toelaat, maar verticaal slechts 40°C

[Voor 26% gewijzigd door nYzEkE op 26-09-2019 19:29]


  • -Paul-
  • Registratie: maart 2004
  • Laatst online: 11:57
Na een paar maanden met de PFC200 geklooid te hebben geef ik het op. Alle Wago spullen op V&A gezet en ik gebruik nu een Arduino met MQTT library die communiceert met Home Assistant. Wat een opluchting. Het is wat minder robuust, maar zoveel makkelijker en goedkoper.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
-Paul- schreef op vrijdag 27 september 2019 @ 12:29:
Na een paar maanden met de PFC200 geklooid te hebben geef ik het op. Alle Wago spullen op V&A gezet en ik gebruik nu een Arduino met MQTT library die communiceert met Home Assistant. Wat een opluchting. Het is wat minder robuust, maar zoveel makkelijker en goedkoper.
Paul, waarom kijk je hier eens niet naar..?
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Het is zeker geen simpele zaak om vanaf nul te beginnen maar in dat project zit waarschijnlijk zo goed als alles wat je nodig hebt met documentatie... moest je dan nog iets tekortkomen hoor ik het graag!

  • TailwindNL
  • Registratie: april 2008
  • Laatst online: 27-02 20:05
Wellicht interessant voor iemand --> DMX native vanuit Wago via een RS232/485 Wago module (750-652).

Hardware setup:
- Wago PFC 200 met e!cockpit
- 750-652 RS232/485 module (in RS485 modus)
- DMX302 3 kanaals dimmer (de bekende van de vrienden van Aliexpress)
- Wat digitale input en output kaarten
- 1 groene pushbutton op een digitale input (hoger dimmen)
- 1 rode pushbutton op een digitale input (lager dimmen)
- 3x GU10 Philips dimtone op 1 output kanaal van de DMX302 module

Ik heb een CFC in elkaar geklikt om te kijken of ik het werkend kreeg. Het resultaat is dat het dimmen werkt, vrij netjes maar ik zie nog wel wat lichte knippering tijdens het dimmen.

Zelf denk ik dat dit kan komen door de beperkte load op de dimmer (ong. 13 watt) of omdat de dimwaardes van 0-100 loopt ipv 0-255. Ik heb nog niet uitvoerig getroubleshoot, maar mocht iemand nog andere ideeën hebben dan zijn die welkom.

De volgende stap is om dit met Mich zijn MQTT te integreren. dwz: scene's via mqtt als input commando naar de wago sturen en dimmen via MQTT mogelijk maken.

Hieronder de CFC:
https://ibb.co/f9XQ1kj

En de testopstelling:
https://ibb.co/KmskR9X

https://ibb.co/0ffN8sD

Als iemand interesse heeft in de projecfiles, laat maar weten.

  • Heire
  • Registratie: juni 2009
  • Laatst online: 17-03 21:27
ThePsycho schreef op woensdag 25 september 2019 @ 22:21:
[...]


Ik gebruik zelf de evaluatieversie van e!cockpit. Er zijn manieren om deze oneindig te verlengen en WAGO lijkt er voor thuisgebruik niet om te geven dat dit gebeurt. Tot nu toe is dit erg makkelijk werken, zeker met de beschikbare libraries.

Ik zou persoonlijk zeggen, laat e!cockpit je vooral niet tegenhouden, het is makkelijk te omzeilen!
En welke manieren heb je zoal om dit te doen :) ?
Dat is het enige waarom ik ecockpit zou behouden gezien de libraries er aanwezig zijn en op zich toch goed werkt.

  • ThePsycho
  • Registratie: oktober 2013
  • Laatst online: 07-04 23:56

ThePsycho

Biertje?

Heire schreef op vrijdag 27 september 2019 @ 20:30:
[...]


En welke manieren heb je zoal om dit te doen :) ?
Dat is het enige waarom ik ecockpit zou behouden gezien de libraries er aanwezig zijn en op zich toch goed werkt.
Members only: e!cockpit DRM
Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Of toch kaas.


  • -Paul-
  • Registratie: maart 2004
  • Laatst online: 11:57
MichVw schreef op vrijdag 27 september 2019 @ 16:51:
[...]


Paul, waarom kijk je hier eens niet naar..?
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Het is zeker geen simpele zaak om vanaf nul te beginnen maar in dat project zit waarschijnlijk zo goed als alles wat je nodig hebt met documentatie... moest je dan nog iets tekortkomen hoor ik het graag!
Ja, dat ziet er veelbelovend uit voor MQTT. Mijn probleem was om DMX aan de praat te krijgen. Ik wilde alle basisfuncties in de PLC programmeren. Maar zowel via de 750-652 als via ArtNet niet gelukt.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
TailwindNL schreef op vrijdag 27 september 2019 @ 20:04:

Als iemand interesse heeft in de projecfiles, laat maar weten.
Ik heb altijd interesse in projectfiles, waarschijnlijk zal je vanuit e!cockpit wel een export moeten nemen naar iets dat CoDeSys ook kan lezen..

  • TailwindNL
  • Registratie: april 2008
  • Laatst online: 27-02 20:05
MichVw schreef op zaterdag 28 september 2019 @ 11:31:
[...]


Ik heb altijd interesse in projectfiles, waarschijnlijk zal je vanuit e!cockpit wel een export moeten nemen naar iets dat CoDeSys ook kan lezen..
Mjaah....maar daar heb je waarschijnlijk niet veel aan, want ik heb ergens gelezen dat het niet mogelijk is om de 750-652 te gebruiken met Codesys. Je kan wel e!cockpit naast codesys installeren, dan kan je beide gebruiken (en meteen vanuit e!cockpit de libraries van de codesys installatie toevoegen zodat jouw mqtt project ook werkt vanuit e!cockpit ;) ).

Hier de link naar het .export bestand: https://gofile.io/?c=hbKG0N

Laat maar weten of het gelukt is, of dat je nog dingen mist.

  • THM0
  • Registratie: juli 2006
  • Laatst online: 13:04
Let wel op met de 750-652 voor DMX: die module heeft een firmware welke niet upgradable is, en de DMX library van Wago ondersteunt niet alle firmwares, en bij bepaalde versies is het aantal ondersteunde kanalen beperkt. Zie de DMX application note voor de details. Even opletten dus als je er een van marktplaats of ebay haalt.

  • smaertens
  • Registratie: januari 2019
  • Laatst online: 07-04 10:05
Hallo,

Hier ook een kast gemaakt op basis van de Wago Plc.

Ik heb de allereerste lichten werkend gekregen.

Hoe gaan jullie eigenlijk om met de uitgangen persistent te houden?
Als je kaarten toevoegt aan de PLC kan je bij device / Local Bus IO Mapping er een naam aan toevoegen.
Die variabele wordt dan automatisch gecreeerd in de IOConfig_Globals_Mapping lijst.
Kan je bij die lijst ergens het woord Persistent toevoegen? Of hoe doen jullie dit?


Het doel is eigenlijk, dat wanneer ik de programmatie update (ben nog volop aan het schrijven) dat niet telkens in het hele huis de lichten uitgaan :)

Hartelijk dank!

  • OcGuru
  • Registratie: juni 2004
  • Laatst online: 07-04 23:24

OcGuru

Giulietta Qv

MichVw schreef op donderdag 26 september 2019 @ 12:14:
[...]


goeie vraag, ik heb al eens rondgekeke en rondgevraagd aan andere mensen met meer ervaring met de WAGO PFC maar momenteel kom ik er alleen op terug dat het momenteel niet mogelijk is.. :|
spijtig, maar los daarvan moet ik nog een goed bekijken of het nuttig is om HVAC basis functionaliteit in de PLC te steken.. Temperatuur metingen blijven daarbij een pijnpunt voor het moment.. alle input is zeker welkom op dit vlak!
Voor mijn hvac regeling gebruik ik deze modules. https://nl.aliexpress.com...1602_5,searchweb201603_52

ds18b20 sensoren kosten geen drol bij ali en je leest ze gewoon uit via modbus. :)
Zulke modules bestaan ook voor RTD sensoren. Maar die zijn iets duurder.

[Voor 3% gewijzigd door OcGuru op 28-09-2019 16:28]

Bl44t


  • UglyDinosaur
  • Registratie: november 2018
  • Laatst online: 12:45
OcGuru schreef op zaterdag 28 september 2019 @ 16:25:
[...]

Voor mijn hvac regeling gebruik ik deze modules. https://nl.aliexpress.com...1602_5,searchweb201603_52

ds18b20 sensoren kosten geen drol bij ali en je leest ze gewoon uit via modbus. :)
Zulke modules bestaan ook voor RTD sensoren. Maar die zijn iets duurder.
Dat ziet er wel interessant uit. Makkelijk te installeren en programmeren? Heb je daarvoor nog aparte software nodig om dat te programmeren?

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
smaertens schreef op zaterdag 28 september 2019 @ 16:20:
Hallo,

Hier ook een kast gemaakt op basis van de Wago Plc.

Ik heb de allereerste lichten werkend gekregen.

Hoe gaan jullie eigenlijk om met de uitgangen persistent te houden?
Als je kaarten toevoegt aan de PLC kan je bij device / Local Bus IO Mapping er een naam aan toevoegen.
Die variabele wordt dan automatisch gecreeerd in de IOConfig_Globals_Mapping lijst.
Kan je bij die lijst ergens het woord Persistent toevoegen? Of hoe doen jullie dit?


Het doel is eigenlijk, dat wanneer ik de programmatie update (ben nog volop aan het schrijven) dat niet telkens in het hele huis de lichten uitgaan :)

Hartelijk dank!
Je dien een stuk VAR PERSISTENT aan te maken in de FB waar je waardes wilt gaan onthouden. Je hebt ook persistent variable list nodig en moet die dan telkens updaten als je een nieuwe FB maakt waar persistent variables in zitten. In mijn project maak ik er gebruik van in de fb_output_switch_mqtt, kan je hier vinden:
https://github.com/Michie...e/HomeAutomation.CoDeSys3
in de getting started docs word er ook vermeld hoe je die persistent variable list moet updaten:
https://github.com/Michie.../Getting_started_guide.md

EDIT: persistent vars zijn wel geen garantie voor als je je programma gaat aanpassen, zijn vooral voor powercycles..

[Voor 4% gewijzigd door MichVw op 29-09-2019 10:27]


  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
TailwindNL schreef op zaterdag 28 september 2019 @ 13:57:
[...]


Mjaah....maar daar heb je waarschijnlijk niet veel aan, want ik heb ergens gelezen dat het niet mogelijk is om de 750-652 te gebruiken met Codesys. Je kan wel e!cockpit naast codesys installeren, dan kan je beide gebruiken (en meteen vanuit e!cockpit de libraries van de codesys installatie toevoegen zodat jouw mqtt project ook werkt vanuit e!cockpit ;) ).

Hier de link naar het .export bestand: https://gofile.io/?c=hbKG0N

Laat maar weten of het gelukt is, of dat je nog dingen mist.
Ik probeer het komende week te bekijken en ga dan meteen ook eens e!cockpit proberen ;)

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
THM0 schreef op zaterdag 28 september 2019 @ 15:23:
Let wel op met de 750-652 voor DMX: die module heeft een firmware welke niet upgradable is, en de DMX library van Wago ondersteunt niet alle firmwares, en bij bepaalde versies is het aantal ondersteunde kanalen beperkt. Zie de DMX application note voor de details. Even opletten dus als je er een van marktplaats of ebay haalt.
kan je toevallig rond dat probleem werken door de interne rs485 poort te gebruiken van de PLC? de DMX ondersteuning op de PFC's zijn precies niet ideaal als ik het hier zo hoor. Bestaat er geen modelijkheid om sturing te doen via Artnet aan de hand van de PLC Ethernet poort?

  • VBP8501
  • Registratie: februari 2017
  • Laatst online: 04-04 21:35
Ik heb mij een 750-652 aangeschaft via ebay om DMX lichtsturing te doen. Ik had al een ArtNet-DMX UNIVERSE DR 1.1 maar had last van flikkeringen. Dus ik dacht dat het misschien aan de gateway lag. Plus om alles rechtstreeks via de plc te doen leek mij ook prettiger.

MAAR nu blijkt dat ik ook Wago IO Check nodig heb om die 750-652 te configureren in DMX modus? Dus dat is nog een 200€ erbovenop? Is er een alternatief? Is er iemand die misschien in de buurt van Kampenhout (BE) woont met die licentie? :)
THM0 schreef op zaterdag 28 september 2019 @ 15:23:
Let wel op met de 750-652 voor DMX: die module heeft een firmware welke niet upgradable is, en de DMX library van Wago ondersteunt niet alle firmwares, en bij bepaalde versies is het aantal ondersteunde kanalen beperkt. Zie de DMX application note voor de details. Even opletten dus als je er een van marktplaats of ebay haalt.
Goede tip (spijtig genoeg te laat gezien...).. Hoe weet ik welke firmware ik heb?

[Voor 34% gewijzigd door VBP8501 op 29-09-2019 13:45]


  • tinus5
  • Registratie: maart 2012
  • Laatst online: 12:57
VBP8501 schreef op zondag 29 september 2019 @ 13:44:
MAAR nu blijkt dat ik ook Wago IO Check nodig heb om die 750-652 te configureren in DMX modus? Dus dat is nog een 200€ erbovenop? Is er een alternatief? Is er iemand die misschien in de buurt van Kampenhout (BE) woont met die licentie? :)
[...]

Goede tip (spijtig genoeg te laat gezien...).. Hoe weet ik welke firmware ik heb?
Ik heb wel Wago IO Check, maar niet echt in de buurt van Kampenhout (Almere). Ik heb het toen bij Conrad voor €102 gekocht. Mocht je echt omhoog zitten, dan moet je maar contact opnemenhoe we het eventueel handig kunnen regelen.

Mijn 750-652 heeft firmware versie 01.01.10(04) en daar werkt DMX iig mee

[Voor 5% gewijzigd door tinus5 op 29-09-2019 14:19. Reden: add firmware versie]


  • THM0
  • Registratie: juli 2006
  • Laatst online: 13:04
VBP8501 schreef op zondag 29 september 2019 @ 13:44:
Ik heb mij een 750-652 aangeschaft via ebay om DMX lichtsturing te doen. Ik had al een ArtNet-DMX UNIVERSE DR 1.1 maar had last van flikkeringen. Dus ik dacht dat het misschien aan de gateway lag. Plus om alles rechtstreeks via de plc te doen leek mij ook prettiger.

MAAR nu blijkt dat ik ook Wago IO Check nodig heb om die 750-652 te configureren in DMX modus? Dus dat is nog een 200€ erbovenop? Is er een alternatief? Is er iemand die misschien in de buurt van Kampenhout (BE) woont met die licentie? :)


[...]

Goede tip (spijtig genoeg te laat gezien...).. Hoe weet ik welke firmware ik heb?
De firmware kun je uitlezen met I/O Check :')

Maar I/O Check krijg je toch gewoon geinstalleerd bij e!Cockpit?
Je kunt het ook op de zijkant van de module zien. Daar staat ergens een 8-cijferig getal gevolgd door streepjes en nog wat cijfers. Eerste vier cijfers zijn productieweek en -jaar, gevolgd door twee cijfers die de firmware versie aangeven.

Dit zegt Wago trouwens over de firmware compatibiliteit:
Note
The DMX function is only possible using WAGO 750-652 Serial Module from firmware version 03. For FW 03 until FW05, maximum 21 or 45 DMX channel can be sent depends on the Process Image setting of the module. From FW 06 maximum 512 DMX channel can be sent.
Firmware 06 kan ook DMX berichten ontvangen/uitlezen.

[Voor 14% gewijzigd door THM0 op 29-09-2019 14:47]


  • THM0
  • Registratie: juli 2006
  • Laatst online: 13:04
MichVw schreef op zondag 29 september 2019 @ 10:23:
[...]


kan je toevallig rond dat probleem werken door de interne rs485 poort te gebruiken van de PLC? de DMX ondersteuning op de PFC's zijn precies niet ideaal als ik het hier zo hoor. Bestaat er geen modelijkheid om sturing te doen via Artnet aan de hand van de PLC Ethernet poort?
Nee dat kan niet volgens mij. I/O Check heeft echt een DMX instelling voor de 750-652 module. Die instelling is er niet voor het seriele interface op de PLC zelf.

Ik weet niet wat het wel/of niet ideaal maakt voor je. Je hebt gewoon een functionblock waarin je kunt zeggen: 'dit kanaal naar deze waarde'. En dan heb je in de Building libraries allerlei function blocks om met Scenes te werken. Ik heb vooralsnog alleen de documentatie doorgenomen. Het ziet er uit als best wel flexibel, maar kost wel even tijd om het goed te begrijpen.

  • OcGuru
  • Registratie: juni 2004
  • Laatst online: 07-04 23:24

OcGuru

Giulietta Qv

benbam schreef op zondag 29 september 2019 @ 09:37:
[...]


Dat ziet er wel interessant uit. Makkelijk te installeren en programmeren? Heb je daarvoor nog aparte software nodig om dat te programmeren?
Jazeker. je sluit de sensor aan op de module en je kan hem direct uitlezen dmv modbus rtu.

Zit ook software bij, maar dat is alleen om de module een ander adres te geven en eventuele de communicatie instellingen te veranderen(baud rate, parity etc)

Bl44t


  • VBP8501
  • Registratie: februari 2017
  • Laatst online: 04-04 21:35
[b]THM0 in "Domotica met plc's"
De firmware kun je uitlezen met I/O Check :')

Maar I/O Check krijg je toch gewoon geinstalleerd bij e!Cockpit?
Je kunt het ook op de zijkant van de module zien. Daar staat ergens een 8-cijferig getal gevolgd door streepjes en nog wat cijfers. Eerste vier cijfers zijn productieweek en -jaar, gevolgd door twee cijfers die de firmware versie aangeven.
Allez ik heb v6, daar heb ik dan wel geluk gehad.

Ik heb geen e!Cockpit maar Codesys 2.3. Had een starterskit met 750-881 gekocht. Dus geen IO check voor mij :(
https://www.wago.com/glob...03-001_K999-9999_000-1600

  • THM0
  • Registratie: juli 2006
  • Laatst online: 13:04
VBP8501 schreef op zondag 29 september 2019 @ 15:58:
[...]

Allez ik heb v6, daar heb ik dan wel geluk gehad.

Ik heb geen e!Cockpit maar Codesys 2.3. Had een starterskit met 750-881 gekocht. Dus geen IO check voor mij :(
https://www.wago.com/glob...03-001_K999-9999_000-1600
Je kunt toch gewoon de e!Cockpit trial downloaden en installeren? Wellicht in een Virtual Machine, want kan me voorstellen dat ie niet lekker combineert met Codesys 2.3. Wellicht kan het ook remote over een VPN; I/O Check verbindt gewoon over ethernet.

  • VBP8501
  • Registratie: februari 2017
  • Laatst online: 04-04 21:35
THM0 schreef op zondag 29 september 2019 @ 16:31:
[...]

Je kunt toch gewoon de e!Cockpit trial downloaden en installeren? Wellicht in een Virtual Machine, want kan me voorstellen dat ie niet lekker combineert met Codesys 2.3. Wellicht kan het ook remote over een VPN; I/O Check verbindt gewoon over ethernet.
Dat is misschien een optie ja.

Heb ondertussen nog wat verder zitten troubleshooten en het probleem van de flikkerende ledjes heeft uiteindelijk niets met DMX te maken (ik dacht dat het aan de DMX interface lag). Ik gebruik van die eldoled powerdrive 180D drivers waarbij ik mijn ledjes in parallel moet aansluiten. Als ik de eldoled in "show modus" zet (dus dmx negeren) dan flikkeren de ledjes nog.

Zijn het nu de ledjes of de driver... Ik had ze liever in serie aangesloten maar dan kan ik niet genoeg spanning geven.. :?

Update: heb nagemeten met de oscilloscope, amper spanningsvariatie aan de uitgang van de power supplies. Maar wel zeer veel aan de uitgang van de drivers. Zelfs met maar 1 spotjes blijft het flikkeren. Dus het probleem is ook niet in de parallelschakeling.
't zou mij verbazen dat ik 20 defecte spotjes heb gekregen.. Maar 't zou mij ook verbazen dat ik 3 defecte led drivers heb (heb er in totaal 5 maar 2 nog niet aangesloten)

[Voor 19% gewijzigd door VBP8501 op 29-09-2019 18:11]


  • UglyDinosaur
  • Registratie: november 2018
  • Laatst online: 12:45
Deze namiddag wou ik mijn programmatie uitbreiden zodat ik door middel van mqtt berichten mijn outputs kon schakelen in codesys. Ik wou hiervoor de library van rossmann-engineering gebruiken (http://codesys-mqtt-library.sourceforge.net/) aangezien deze al goed werkt om te publishen vanuit codesys.

Helaas blijkt het subscriben niet zo vlot te lopen. Als je de FB verschillende keren gebruikt om te subscriben op verschillende topics gooit hij na verloop van tijd alles door elkaar en krijg je ineens op je output van de FB boodschappen van verschillende topics en niet meer van de topic waarop die bepaalde FB ge-subscribed is...

Er is vorig jaar an een topic gepost daarover op sourceforge, maar zo te zien is er geen oplossing uit de bus gekomen... Helaas want had het wel graag aan het werken gekregen...

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
benbam schreef op zondag 29 september 2019 @ 20:43:
Deze namiddag wou ik mijn programmatie uitbreiden zodat ik door middel van mqtt berichten mijn outputs kon schakelen in codesys. Ik wou hiervoor de library van rossmann-engineering gebruiken (http://codesys-mqtt-library.sourceforge.net/) aangezien deze al goed werkt om te publishen vanuit codesys.

Helaas blijkt het subscriben niet zo vlot te lopen. Als je de FB verschillende keren gebruikt om te subscriben op verschillende topics gooit hij na verloop van tijd alles door elkaar en krijg je ineens op je output van de FB boodschappen van verschillende topics en niet meer van de topic waarop die bepaalde FB ge-subscribed is...

Er is vorig jaar an een topic gepost daarover op sourceforge, maar zo te zien is er geen oplossing uit de bus gekomen... Helaas want had het wel graag aan het werken gekregen...
Ik zou weg blijven van die rossman engineering library, laatste update jaren geleden (2017) en enkel support voor QoS 0.. Ik gebruik nu al even deze: https://github.com/stefandreyer/CODESYS-MQTT en ondervond geen problemen, ondersteund ook QoS 2 wat toch niet onbelangrijk is naar betrouwbaarheid van je setup. De ontwikkelaar reageert ook atlijd vlot op git issues en er zitten enkele voorbeelden in de repo ook.

Je kan ook een reference architectuur vinden met enkele FB die reeds mqtt enabled zijn op m'n repo hier:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Probeer er misschien eens naar te kijken, als we met enkele tweakers zelfde architectuur en FB gebruiken kunnen we op korte tijd iets heel betrouwbaar maken voor iedereen ;)

  • UglyDinosaur
  • Registratie: november 2018
  • Laatst online: 12:45
MichVw schreef op maandag 30 september 2019 @ 10:02:
[...]


Ik zou weg blijven van die rossman engineering library, laatste update jaren geleden (2017) en enkel support voor QoS 0.. Ik gebruik nu al even deze: https://github.com/stefandreyer/CODESYS-MQTT en ondervond geen problemen, ondersteund ook QoS 2 wat toch niet onbelangrijk is naar betrouwbaarheid van je setup. De ontwikkelaar reageert ook atlijd vlot op git issues en er zitten enkele voorbeelden in de repo ook.

Je kan ook een reference architectuur vinden met enkele FB die reeds mqtt enabled zijn op m'n repo hier:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Probeer er misschien eens naar te kijken, als we met enkele tweakers zelfde architectuur en FB gebruiken kunnen we op korte tijd iets heel betrouwbaar maken voor iedereen ;)
Ja, daar had ik ook naar gekeken, maar ik kan er eigenlijk helemaal niet aan uit hoe dat allemaal werkt... Als het niet met eenvoudige function blocks werkt gaat het al snel mijn petje te boven. Ik kon in de voorbeelden enkel een hoop code vinden waar ik niets van snapte...

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
benbam schreef op maandag 30 september 2019 @ 10:22:
[...]


Ja, daar had ik ook naar gekeken, maar ik kan er eigenlijk helemaal niet aan uit hoe dat allemaal werkt... Als het niet met eenvoudige function blocks werkt gaat het al snel mijn petje te boven. Ik kon in de voorbeelden enkel een hoop code vinden waar ik niets van snapte...
ook met de reference architectuur op m'n git? daar zit alle MQTT functionaliteit al ingebakken en zou je er moeten aan uit geraken met wat copy/paste werk. Er is ook een getting started guide:
https://github.com/Michie.../Getting_started_guide.md

  • smaertens
  • Registratie: januari 2019
  • Laatst online: 07-04 10:05
MichVw schreef op zondag 29 september 2019 @ 10:12:
[...]


Je dien een stuk VAR PERSISTENT aan te maken in de FB waar je waardes wilt gaan onthouden. Je hebt ook persistent variable list nodig en moet die dan telkens updaten als je een nieuwe FB maakt waar persistent variables in zitten. In mijn project maak ik er gebruik van in de fb_output_switch_mqtt, kan je hier vinden:
https://github.com/Michie...e/HomeAutomation.CoDeSys3
in de getting started docs word er ook vermeld hoe je die persistent variable list moet updaten:
https://github.com/Michie.../Getting_started_guide.md

EDIT: persistent vars zijn wel geen garantie voor als je je programma gaat aanpassen, zijn vooral voor powercycles..
Dankjewel! Ik heb je project ook eens bekeken. Heb je daar ook dimmers in zitten? Ik gebruik voor mijn verlichting meanwell voedingen die ik stuur met 0-10Volt. Ik gebruik daar de Fb_DIm_SingleButton voor.

Voor de visualisatie ben ik de interne webserver van de wago PLC eens aan het bekijken; Iemand soms een idee of er daar bijkomstige bibliotheken voor beschikbaar zijn ergens met andere symbolen als de standard die er in zit, (Ik gebruik E-Cockpit)

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
smaertens schreef op donderdag 3 oktober 2019 @ 22:22:
[...]


Dankjewel! Ik heb je project ook eens bekeken. Heb je daar ook dimmers in zitten? Ik gebruik voor mijn verlichting meanwell voedingen die ik stuur met 0-10Volt. Ik gebruik daar de Fb_DIm_SingleButton voor.

Voor de visualisatie ben ik de interne webserver van de wago PLC eens aan het bekijken; Iemand soms een idee of er daar bijkomstige bibliotheken voor beschikbaar zijn ergens met andere symbolen als de standard die er in zit, (Ik gebruik E-Cockpit)
ik heb een input FB om een pushutton (link) aan te linken die dimmer values kan genereren maar nog geen output FB om de waarden van meerdere dimmer input FB's aan te linken met bijhorende MQTT subscripties. Probleem is vooral dat ik geen analoge output liggen heb.. Stuur me gerust een PM of maak een git issue aan en dan geraken we er wel als je het ziet zitten om te testen wat ik fabriceer ;)

betreffende visualisatie, waarom gewoon geen Home Assistant Locelace op een Rpi of iets gelijkaardig? Qua looks zal je het beter niet zeker krijgen via iets op de PLC

Acties:
  • +3Henk 'm!

  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
Ik werk momenteel aan een vademecum voor Structured Text zoals gedefinieerd in IEC 611311-3. Het is een work-in-progress maar het kan misschien al nuttig zijn voor iemand dus heb ik het gepubliceerd.

Bitbucket repo

  • VBP8501
  • Registratie: februari 2017
  • Laatst online: 04-04 21:35
VBP8501 schreef op zondag 29 september 2019 @ 16:40:
[...]
Zijn het nu de ledjes of de driver... Ik had ze liever in serie aangesloten maar dan kan ik niet genoeg spanning geven.. :?
Even terugkoppelen. Het probleem was dat ik een common ground had gebruikt aan de kanalen van de eldoled drivers. Dat mag dus niet... De exacte fysica erachter begrijp ik niet maar als ik de brugjes over mijn rijgklemmen weghaal dan flikkeren de leds niet meer.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
ik heb eens even de tijd genomen dit weekend om te bekijken wat Wago allemaal beschikbaar stelt in z'n HVAC library en dat is toch pittige materie om te verwerken. De functieblokken zijn dan ook echt gemaakt om het volledige automatisatie process van je huis in de PLC te steken. Iets wat de meesten dan hier weer in Node-Red, openHAB, Home-Assistant, Domoticz zouden doen dus wat vergaand.. Niet onlogisch natuurlijk voor een bedrijf dat PLC's verkoopt dat ze alles van programmatie in de PLC doen.. :)

Ik vind het wat vergaand en blijf bij het principe om enkel basiszaken in de PLC te gaan steken en aan de hand van MQTT communicatie naar de plc meer complexe automatisatie te gaan doen. Betreffende HVAC begint die zoektocht nu wat.. Daarom een open vraag: zijn hier mensen die ervaring hebben met HVAC op een professioneel niveau? Bijvoorbeeld om ventielen te gaan aansturen voor vloerverwarming via PLC?

  • UglyDinosaur
  • Registratie: november 2018
  • Laatst online: 12:45
MichVw schreef op maandag 7 oktober 2019 @ 10:47:
ik heb eens even de tijd genomen dit weekend om te bekijken wat Wago allemaal beschikbaar stelt in z'n HVAC library en dat is toch pittige materie om te verwerken. De functieblokken zijn dan ook echt gemaakt om het volledige automatisatie process van je huis in de PLC te steken. Iets wat de meesten dan hier weer in Node-Red, openHAB, Home-Assistant, Domoticz zouden doen dus wat vergaand.. Niet onlogisch natuurlijk voor een bedrijf dat PLC's verkoopt dat ze alles van programmatie in de PLC doen.. :)

Ik vind het wat vergaand en blijf bij het principe om enkel basiszaken in de PLC te gaan steken en aan de hand van MQTT communicatie naar de plc meer complexe automatisatie te gaan doen. Betreffende HVAC begint die zoektocht nu wat.. Daarom een open vraag: zijn hier mensen die ervaring hebben met HVAC op een professioneel niveau? Bijvoorbeeld om ventielen te gaan aansturen voor vloerverwarming via PLC?
Ik doe dit zo. Dus als je vragen hebt...
Ik ben het overigens niet met je eens om enkel de basiszaken in de PLC te steken. Ik vind mijn verwarming thuis te belangrijk om te laten werken met MQTT of met een raspberry of dergelijke er tussen. Mijn raspberry is (met SSD trouwens) al een paar keer in storing gegaan en dat zou ik liever niet hebben op mijn verwarming. De PLC is veel betrouwbaarder. Ik heb nu een NUC aangekocht waarmee ik de raspbery ga vervangen.

Ik heb de library en visualisatie aangekocht van deze aanbieder https://www.hvac-automation.com/en/.
Het was een pittige leercurve, maar alles werkt nu toch min of meer. Ik stuur wel enkel ventielen. De ketel en de pomp stuur ik op basis van warmtevraag in één van de kringen met relais (zou ook makkelijk met de PLC en enkele relais kunnen) en temperatuur van de ketel stel ik handmatig in.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
benbam schreef op maandag 7 oktober 2019 @ 12:35:
[...]


Ik doe dit zo. Dus als je vragen hebt...
Ik ben het overigens niet met je eens om enkel de basiszaken in de PLC te steken. Ik vind mijn verwarming thuis te belangrijk om te laten werken met MQTT of met een raspberry of dergelijke er tussen. Mijn raspberry is (met SSD trouwens) al een paar keer in storing gegaan en dat zou ik liever niet hebben op mijn verwarming. De PLC is veel betrouwbaarder. Ik heb nu een NUC aangekocht waarmee ik de raspbery ga vervangen.

Ik heb de library en visualisatie aangekocht van deze aanbieder https://www.hvac-automation.com/en/.
Het was een pittige leercurve, maar alles werkt nu toch min of meer. Ik stuur wel enkel ventielen. De ketel en de pomp stuur ik op basis van warmtevraag in één van de kringen met relais (zou ook makkelijk met de PLC en enkele relais kunnen) en temperatuur van de ketel stel ik handmatig in.
'basis' is misschien wat teveel voor interpretatie vatbaar ;) Ik bedoel we degelijk dat m'n huis moet kunnen werken met enkel de PLC, maar ik wil ook kunnen interfacen met MQTT om bepaalde zaken mogelijk te maken (nog geen idee wat, maar de mogelijkheid tot integratie is gewoon belangrijk voor me).

Paar vraagjes:
  • Die library ziet er inderdaad zeer interessant uit! is die €90 per device?
  • Welke functieblok gebruik je om je ventielen voor vloerverwarming aan te sturen?
  • Ik veronderstel dat je om alles correct te doen verlopen ook temperatuursmeetingen in je plc krijgt, hoe doe je dat (hardware appraoch)?
  • Welke ventielen (hardware) gebruik je zodat je ze kan aansturen vanuit de PLC?

  • renedis
  • Registratie: juli 2003
  • Laatst online: 31-03 14:20
Femme schreef op dinsdag 17 september 2019 @ 12:21:
Wat betreft je wens om iets krachtigers dan een single board computer te gebruiken: er zijn tegenwoordig echt leuke bordjes met goede performance en veel mogelijkheden. Zo heb ik nu thuis een Khadas VIM3 liggen die net zo compact is als een RPi, maar wel een hexacore heeft (4x A73 op 2,2GHz en 2x A53 op 1,8GHz) met 4GB RAM, 32GB eMMC geheugen en een m.2-slot voor een ssd. Dus snel, zuinig en betrouwbare opslag.
Wat zijn je bevindingen op gebied van de VIM3?

Ik zit te kijken naar een Odroid N2 en een Khadas VIM3. De VIM3 is kwa specs net een stukje beter dan de N2. Maar ik maak me zorgen om de temperaturen? Kan jij daar misschien iets zinnigs over zeggen? Community support is volgens mij bij beide hetzelfde..

  • UglyDinosaur
  • Registratie: november 2018
  • Laatst online: 12:45
MichVw schreef op maandag 7 oktober 2019 @ 13:06:
[...]


'basis' is misschien wat teveel voor interpretatie vatbaar ;) Ik bedoel we degelijk dat m'n huis moet kunnen werken met enkel de PLC, maar ik wil ook kunnen interfacen met MQTT om bepaalde zaken mogelijk te maken (nog geen idee wat, maar de mogelijkheid tot integratie is gewoon belangrijk voor me).

Paar vraagjes:
  • Die library ziet er inderdaad zeer interessant uit! is die €90 per device?
  • Welke functieblok gebruik je om je ventielen voor vloerverwarming aan te sturen?
  • Ik veronderstel dat je om alles correct te doen verlopen ook temperatuursmeetingen in je plc krijgt, hoe doe je dat (hardware appraoch)?
  • Welke ventielen (hardware) gebruik je zodat je ze kan aansturen vanuit de PLC?
Die library ziet er inderdaad zeer interessant uit! is die €90 per device?

Ik vermoed van wel. Heb me er eigenlijk geen vragen bij gesteld aangezien ik er maar 1 heb. Maar aangezien je een licentie moet installeren denk ik het wel.

Welke functieblok gebruik je om je ventielen voor vloerverwarming aan te sturen?

In de library zitten speciale functieblokken die samen werken met de visualisatie. Afhankelijke van de gevraagde temperatuur, de gemeten temperatuur en de klokinstellingen (en nog meer als je wilt) wordt er een uitgang geschakeld. Hiermee kan je dan het ventiel aansturen.

Ik veronderstel dat je om alles correct te doen verlopen ook temperatuursmeetingen in je plc krijgt, hoe doe je dat (hardware appraoch)?

Zoals hier reeds in het verleden aangehaald: via 1-wire -> arduino -> Modbus TCP ->PLC.

Welke ventielen (hardware) gebruik je zodat je ze kan aansturen vanuit de PLC?

Gewone 24V zoneventielen op de collector gemonteerd. De uitgang van de PLC stuurt een relais aan dat 24V naar het ventiel stuurt.

  • matthijs33
  • Registratie: oktober 2010
  • Laatst online: 07-04 12:53
Afgelopen weekend is mijn tuinhuis geplaatst, en ben nu aan het kijken voor de verlichting.

Er licht een dikke wachtbuis (dia 5cm) van de meterkast rechtstreeks naar het tuinhuis (~25 meter).
Hier trek ik zeker 3x2.5mm² door voor de stopcontacten, maar ben nu aan het twijfelen hoe ik de verlichting ga doen. Ik denk er 3 afzonderlijk bedienbare lichtpunten te hebben. Ik zou deze op de kabel voor de stopcontacten kunnen aansluiten (en met wisselschakelaars werken), maar dan zijn deze dus niet gekoppeld met de PLC. Er moeten dus betere opties zijn:
  1. 3 keer 3g1.5mm² + een CAT5 voor de pulsdrukkers naar het tuinhuis te trekken.
  2. 1 keer 5g1.5mm² + een CAT5 voor de pulsdrukkers naar het tuinhuis te trekken.
  3. een CAT5 voor de pulsdrukkers en relais naar het tuinhuis te trekken. Hierbij zou dan een klein kastje met 3 relais in het tuinhuis komen. Heeft er iemand een afstand van ~25 meter tussen de relais en de PLC? Zou dit problemen kunnen geven?
Ik denk voorlopig voor de 5g1.5mm² te gaan, dit lijkt me het eenvoudigst, hiermee blijven alle relais samen en de extra kabel is misschien zelfs goedkoper dan dat extra kastje.

  • Femme
  • Registratie: juni 1999
  • Laatst online: 12:00

Femme

Hardwareconnaisseur

Official Jony Ive fan

Topicstarter
matthijs33 schreef op dinsdag 8 oktober 2019 @ 19:23:

• een CAT5 voor de pulsdrukkers en relais naar het tuinhuis te trekken. Hierbij zou dan een klein kastje met 3 relais in het tuinhuis komen. Heeft er iemand een afstand van ~25 meter tussen de relais en de PLC? Zou dit problemen kunnen geven?
Ik zou inderdaad gewoon een relaiskastje ophangen in het tuinhuis. 25 meter is geen probleem als stuurkabel. In plaats van utp-kabel zou je ook svv-kabel kunnen gebruiken (o.a. te krijgen bij DMLights). Die kun je krijgen in verschillende varianten tot 24 aders per kabel. De aders hebben een 0,50mm2 vaste kern, al snel het dubbele dus van utp.

  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
Wie heeft er ervaring met de bekende DMX302 Aliexpress DMX dimmers te koppelen aan een PFC200?

  • bokkie72
  • Registratie: maart 2010
  • Laatst online: 12:19
In een opwelling heb ik overtallige beckhoff terminals van mijn werkgever over genomen, met het idee om ze voor domotica te gebruiken. Nu ze eenmaal thuis merk ik dat ik er geen tijd voor heb.
Op marktplaats, tweakers en ebay te koop gezet maar niet echt reacties gekregen. Heeft iemand misschien een tip voor alternatief verkoopkanaal/opkoper?

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
ik zou even hulp nodig hebben van iemand die CodeSys3.5 (niet é!cockpit) en een PFC200 gebruikt. Normaal heb ik gevonden hoe de userleds kunnen aangestuurd worden maar door omstandigheden kan ik het zelf niet testen. Kan iemand onderstaand lijntje code proberen:

PFC.SetLed(which:=PFC.LED.U1, how:=PFC.LedState.STATIC_GRN);

En nagaan of er dan effectief een groen ledje gaat branden bij userled 1?
Je hoeft er enkel nog voor te zorgen dat je library CmpPfx200 hebt staan in je libraries. Ik ben je eeuwig dankbaar :)

Los daarvan; de Eastron SMD toestellen maken het mogelijk om vlot energie verbruik uit te lezen via Modbus/RS485. Ik zoek nu al even naar iets gelijkaardig voor waterverbruik... zijn er mensen die hier ervaring mee hebben of ideetjes hebben?

  • mpdevries84
  • Registratie: augustus 2018
  • Laatst online: 07-04 12:34
MichVw schreef op dinsdag 15 oktober 2019 @ 16:12:
ik zou even hulp nodig hebben van iemand die CodeSys3.5 (niet é!cockpit) en een PFC200 gebruikt. Normaal heb ik gevonden hoe de userleds kunnen aangestuurd worden maar door omstandigheden kan ik het zelf niet testen. Kan iemand onderstaand lijntje code proberen:

PFC.SetLed(which:=PFC.LED.U1, how:=PFC.LedState.STATIC_GRN);

En nagaan of er dan effectief een groen ledje gaat branden bij userled 1?
Je hoeft er enkel nog voor te zorgen dat je library CmpPfx200 hebt staan in je libraries. Ik ben je eeuwig dankbaar :)

Los daarvan; de Eastron SMD toestellen maken het mogelijk om vlot energie verbruik uit te lezen via Modbus/RS485. Ik zoek nu al even naar iets gelijkaardig voor waterverbruik... zijn er mensen die hier ervaring mee hebben of ideetjes hebben?
Ik kan je hier helaas niet bij helpen MichVw, maar dat wist je al. Ik draai e.e.a via E!cockpit. Zelf heb ik een PFC200 met een heel aantal DI / DO modules. Daarop draait de implementatie van MichVw via MQTT zodat alles realtime en betrouwbaar met Home Assistant is verbonden. Ik kan iedereen aanraden dit te gebruiken. Er is goed over nagedacht en het draait lekker stabiel! Complimenten, ook voor de hulp via de mail :)

Zelf heb ik ook een vraag. Wellicht is er iemand die dit al eerder heeft uitgezocht.
Bewegingsdetectie heb ik (of beter gezegd ga ik) bewerkstelligen d.m.v. de Panasonic PIR amn31112j sensoren eerder genoemd in dit forum. Wat ik echter ook zou willen is het meten van lichtintensiteit in bepaalde vertrekken zodat ik afhankelijk van de hoeveelheid licht in de ruimte verlichting al dan niet in kan schakelen of automatisch uit kan schakelen.

De volgende oplossingen heb ik al overwogen of zijn bekend:
  • Finder (bijvoorbeeld) heeft een relais waarop een lichtsensor is aan te sluiten. Dit relais moet je echter op een DIN-rail plaatsen (ruimte) en voorzien van separate voeding. Wat ik ook een nadeel vind is dat je het uitgangscontact nog altijd inleest als hard contact op een ingang. Het liefst heb ik de digitale / analoge waarde beschikbaar in de PLC of in Home Assistant.
  • Er zijn Arduino / ESP8266 achtige oplossingen, deze zijn goedkoop maar ik wil liever niet afhankelijk zijn van WIFI oplossingen. Daarnaast is er dan per sensor (ESP8266) weer een aparte 5V voeding nodig voor zover ik het zie.Deze moet je weer inbouwen. Als dat wellicht op een robuuste manier ergens in de verdeelkast kan dat is dat wellicht een optie.
  • Dit relais, maar dat lijkt op de oplossing van Finder: https://www.aliexpress.co...1602_2,searchweb201603_52 en heeft dus ook dezelfde nadelen.
Het liefst zou ik dus een analoge sensor hebben die ik in het plafond kan inbouwen en die ik direct kan inlezen via of 1wire, MQTT of via een analoge ingangskaart van de PFC200. Iemand ideeën? Alles is welkom ;)

[Voor 27% gewijzigd door mpdevries84 op 15-10-2019 20:38]


  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
1-wire lichtsensor in de kamer monteren en laten binnenkomen op de PLC? Lijkt me de snelste optie. Esera heeft 1-wire controllers die je via een klem kan aansluiten op een Wago PFC. Het voorbeeld staat op hun website.

Voordeel bij 1-wire is dat je met een enkele controller al een aantal sensors kan uitlezen. Daar spaart ook weer ruimte uit in je kast.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Kanze schreef op dinsdag 15 oktober 2019 @ 21:29:
1-wire lichtsensor in de kamer monteren en laten binnenkomen op de PLC? Lijkt me de snelste optie. Esera heeft 1-wire controllers die je via een klem kan aansluiten op een Wago PFC. Het voorbeeld staat op hun website.

Voordeel bij 1-wire is dat je met een enkele controller al een aantal sensors kan uitlezen. Daar spaart ook weer ruimte uit in je kast.
Heb je hier hierover?
https://www.esera.de/serv...wago-codesys-integration/

goed mee oppassen; de RS232 integratie kan je beschouwen als een optie, maar dan mag je RS485 vergeten (wat een zonde is met die eastron energiemeters). Jammer dat ze bij Esera geen RS485 toestellen hebben, ga ik hun misschien eens een mailtje voor sturen.. Het voorbeeld met Ethernet werkt dan weer met een library voor CodeSys2, niet het nieuwere CodeSys3.. Dus ook niet echt top..

Ga eens polsen bij Esera naar een RS485 model in de toekomst, anders denk ik erover om misschien een custom 1-Wire bridge te maken met een beaglebone black. Die hebben veel IO, eMmc en vallen goed mee van prijs op Aliexpress.

  • UglyDinosaur
  • Registratie: november 2018
  • Laatst online: 12:45
Ik denk dat ik een betere oplossing gevonden heb dan MQTT om te communiceren met de PLC. Per toeval gestoten op OPC AU enkele dagen geleden...

Op de PFC200 draait standaard al een OPC AU server die kan communiceren met compatibele randapparatuur. Je moet in codesys alleen nog even aanvinken welke variabelen je wil kunnen uitwisselen .

Voor node-red bestaan er nodes die werken met OPC AU waardoor je variabelen kan schrijven en uitlezen via een standaard netwerk-verbinden. Al even mee an het experimenteren en heb in codesys bvb een bijkomende input variabele aangemaakt (een reeds aan een ingang gelinkte variabele aansturen werkt blijkbaar niet) en die in node-red met een knop verbonden. Deze variabele in Codesys bijkomend in parallel met mijn input van de fysieke lichtknop gezet en nu kan ik vanuit mijn dashboard van node red mijn verlichting schakelen :)

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
benbam schreef op donderdag 17 oktober 2019 @ 14:11:
Ik denk dat ik een betere oplossing gevonden heb dan MQTT om te communiceren met de PLC. Per toeval gestoten op OPC AU enkele dagen geleden...

Op de PFC200 draait standaard al een OPC AU server die kan communiceren met compatibele randapparatuur. Je moet in codesys alleen nog even aanvinken welke variabelen je wil kunnen uitwisselen .

Voor node-red bestaan er nodes die werken met OPC AU waardoor je variabelen kan schrijven en uitlezen via een standaard netwerk-verbinden. Al even mee an het experimenteren en heb in codesys bvb een bijkomende input variabele aangemaakt (een reeds aan een ingang gelinkte variabele aansturen werkt blijkbaar niet) en die in node-red met een knop verbonden. Deze variabele in Codesys bijkomend in parallel met mijn input van de fysieke lichtknop gezet en nu kan ik vanuit mijn dashboard van node red mijn verlichting schakelen :)
Met OPC kan je zeker veel bereiken, het is niet voor niets veel gebruikt in de industrie. Probleem is (naar mijn mening) dat het niet rechtstreeks integreert met domotica software zoals Home Assistant en OpenHAB 😐

Veel succes ermee alvast!

  • UglyDinosaur
  • Registratie: november 2018
  • Laatst online: 12:45
MichVw schreef op donderdag 17 oktober 2019 @ 19:30:
[...]


Met OPC kan je zeker veel bereiken, het is niet voor niets veel gebruikt in de industrie. Probleem is (naar mijn mening) dat het niet rechtstreeks integreert met domotica software zoals Home Assistant en OpenHAB 😐

Veel succes ermee alvast!
Ik ben aan het proberen alles binnen node red te doen dus voor mij komt het inderdaad goed uit.

  • OcGuru
  • Registratie: juni 2004
  • Laatst online: 07-04 23:24

OcGuru

Giulietta Qv

Iemand enig idee wat voor connector dit is?

https://cdn.automationdir...roducts/large/l_c03tb.jpg

Ben er eentje kwijt van mijn Koyo PLC. En daar vragen ze voor een spare de hoofdprijs. |:(


//edit, laat maar zitten. Heb het al gevonden. Is een phoenix MC connector.

[Voor 19% gewijzigd door OcGuru op 17-10-2019 22:11]

Bl44t


  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
MichVw schreef op donderdag 17 oktober 2019 @ 13:11:
[...]


Heb je hier hierover?
https://www.esera.de/serv...wago-codesys-integration/

goed mee oppassen; de RS232 integratie kan je beschouwen als een optie, maar dan mag je RS485 vergeten (wat een zonde is met die eastron energiemeters). Jammer dat ze bij Esera geen RS485 toestellen hebben, ga ik hun misschien eens een mailtje voor sturen.. Het voorbeeld met Ethernet werkt dan weer met een library voor CodeSys2, niet het nieuwere CodeSys3.. Dus ook niet echt top..

Ga eens polsen bij Esera naar een RS485 model in de toekomst, anders denk ik erover om misschien een custom 1-Wire bridge te maken met een beaglebone black. Die hebben veel IO, eMmc en vallen goed mee van prijs op Aliexpress.
Kan je dit even nader toelichten @MichVw? Ik dacht bij onze nieuwbouw volgend jaar op een dergelijke manier de 1-wire sensors die we gaan plaatsen uit te lezen. Maar daar moet ik dus mee oppassen?

  • Rob Z
  • Registratie: mei 2004
  • Laatst online: 10:40
[...]
Los daarvan; de Eastron SMD toestellen maken het mogelijk om vlot energie verbruik uit te lezen via Modbus/RS485. Ik zoek nu al even naar iets gelijkaardig voor waterverbruik... zijn er mensen die hier ervaring mee hebben of ideetjes hebben?
Waterverbruik wil ik gaan monitoren door met een inductieve sensor de pulsen te tellen van de watermeter.
Zie ook Is deze watermeter uitleesbaar?

(ik weet een mooi formaat voor het opslaan nog niet... liter per minuut? liter per uur?)

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Kanze schreef op vrijdag 18 oktober 2019 @ 10:00:
[...]


Kan je dit even nader toelichten @MichVw? Ik dacht bij onze nieuwbouw volgend jaar op een dergelijke manier de 1-wire sensors die we gaan plaatsen uit te lezen. Maar daar moet ik dus mee oppassen?
is misschien inderdaad niet 100% duidelijk. Ga je gebruik maken van een PFC toestel met onboard RS232/RS485 seriële poort? Dat is namelijk wat ik heb en dan kan je kiezen voor de onboard poort: RS232 of RS485, ik maak gebruik van RS485 om eastron SMD vermogen meters uit te meten dus dan kan ik via de onboard seriële poort geen RS232 meer gaan gebruiken. Esera heeft nog een ethernet model met een wago library maar die wago library is voor de CodeSys2 runtime, als je een PFC model hebt ga je de CodeSys3 runtime gebruiken, die is gewoon veel krachtiger.. Je kan eventueel proberen om de library om te zetten naar CodeSys3 formaat maar je weet natuurlijk nooit wat dat zal geven.. Als laatste optie kan je dan nog een 750 seriële module kopen om RS232 via die module te doen en RS485 via de onboard poort maar die modules zijn aan de prijzige kant, 1-Wire is er tenslotte om betaalbaar een sensor netwerk aan te leggen, dat 'betaalbare' aspect valt dan weg naar mijn mening, het hangt er natuurlijk vanaf hoe groot je portefeuille is :)

Geef gerust je mening, ik ben er zelf ook nog niet aan uit. Ik denk eraan om een te experimenteren met een beaglebone en 1-Wire, die zien er vrij robuust uit, betaalbaar en kunnen normaal RS485 RTU en TCP + MQTT. de beaglebone zou dan een soort bridge zijn tussen 1-Wire en andere protocollen. Maar ik moet ook nog eens nagaan voor hoeveel die tweedehands seriële modellen gaan op ebay, of het allemaal wel de moeite waard is met andere woorden. Ik stuurde ook een mailtje naar Esera met de vraag of er niets van RS485 in de pipeline zit, het zou leuk zijn om alles op RS485 te kunnen zetten :)

Als laatste, ik zie aan je post hier dat je wel dat je ook enorm bezig bent met domotica op de PLC zelf te programmeren. overweeg je eventueel dit te gebruiken?
https://github.com/Michie...e/HomeAutomation.CoDeSys3
Ik probeer Tweakers met een PFC model te groeperen zodat de functionaliteit groeit, vooral naar HVAC is er wel nog wat (denk)werk.

  • Rob Z
  • Registratie: mei 2004
  • Laatst online: 10:40
[...]
Ik denk eraan om een te experimenteren met een beaglebone en 1-Wire, die zien er vrij robuust uit, betaalbaar en kunnen normaal RS485 RTU en TCP + MQTT. de beaglebone zou dan een soort bridge zijn tussen 1-Wire en andere protocollen.
[...]
(Eerder genoemd) Hier loopt een 1-wire lichtsensor op een Arduino met ethernet, die het via Modbus TCP naar de Wago 750-881 PLC stuurt.
De benodigde code daarvoor is vrij gering.
Een timeout is nog niet voorgekomen en e.e.a. komt ook weer overeind na een netwerkonderbreking.
Zodra de tijd het toe laat moet daar nog een handvol DS18B20 temperatuurssensoren bij op.

[Voor 4% gewijzigd door Rob Z op 18-10-2019 15:38]


  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Rob Z schreef op vrijdag 18 oktober 2019 @ 15:36:
[...]

(Eerder genoemd) Hier loopt een 1-wire lichtsensor op een Arduino met ethernet, die het via Modbus TCP naar de Wago 750-881 PLC stuurt.
De benodigde code daarvoor is vrij gering.
Een timeout is nog niet voorgekomen en e.e.a. komt ook weer overeind na een netwerkonderbreking.
Zodra de tijd het toe laat moet daar nog een handvol DS18B20 temperatuurssensoren bij op.
is dat een arduino uno met ethernetshield of iets anders? welk model van lichtsensor gebruik je? Stuur me gerust een PM met die arduino code, ik heb interesse..

Waar ik wat mee inzit is de betrouwbaarheid van zo'n ethernetshield (arduino uno's zelf zijn vrij betrouwbaar), het zou voor HVAC doeleinden zijn en dat is toch vrij belangrijk, dan wil ik iets die even betrouwbaar/robuust is als m'n PLC of toch in de buurt komt..

  • Rob Z
  • Registratie: mei 2004
  • Laatst online: 10:40
Ja een Arduino Uno (kloon denk ik) met een Wiznet 5100 ethernet shield. (Lichtsensor is een BH1750)
Maar voor HVAC zegt mijn gevoel ook Esera...
Hoewel ik er nu een watchdogfunctie in heb zitten. Dan kun je vanuit de PLC actie ondernemen als er wat omvalt in de Arduino ;)

[Voor 5% gewijzigd door Rob Z op 18-10-2019 19:48]


  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
MichVw schreef op vrijdag 18 oktober 2019 @ 15:19:
[...]


is misschien inderdaad niet 100% duidelijk. Ga je gebruik maken van een PFC toestel met onboard RS232/RS485 seriële poort? Dat is namelijk wat ik heb en dan kan je kiezen voor de onboard poort: RS232 of RS485, ik maak gebruik van RS485 om eastron SMD vermogen meters uit te meten dus dan kan ik via de onboard seriële poort geen RS232 meer gaan gebruiken. Esera heeft nog een ethernet model met een wago library maar die wago library is voor de CodeSys2 runtime, als je een PFC model hebt ga je de CodeSys3 runtime gebruiken, die is gewoon veel krachtiger.. Je kan eventueel proberen om de library om te zetten naar CodeSys3 formaat maar je weet natuurlijk nooit wat dat zal geven.. Als laatste optie kan je dan nog een 750 seriële module kopen om RS232 via die module te doen en RS485 via de onboard poort maar die modules zijn aan de prijzige kant, 1-Wire is er tenslotte om betaalbaar een sensor netwerk aan te leggen, dat 'betaalbare' aspect valt dan weg naar mijn mening, het hangt er natuurlijk vanaf hoe groot je portefeuille is :)

Geef gerust je mening, ik ben er zelf ook nog niet aan uit. Ik denk eraan om een te experimenteren met een beaglebone en 1-Wire, die zien er vrij robuust uit, betaalbaar en kunnen normaal RS485 RTU en TCP + MQTT. de beaglebone zou dan een soort bridge zijn tussen 1-Wire en andere protocollen. Maar ik moet ook nog eens nagaan voor hoeveel die tweedehands seriële modellen gaan op ebay, of het allemaal wel de moeite waard is met andere woorden. Ik stuurde ook een mailtje naar Esera met de vraag of er niets van RS485 in de pipeline zit, het zou leuk zijn om alles op RS485 te kunnen zetten :)

Als laatste, ik zie aan je post hier dat je wel dat je ook enorm bezig bent met domotica op de PLC zelf te programmeren. overweeg je eventueel dit te gebruiken?
https://github.com/Michie...e/HomeAutomation.CoDeSys3
Ik probeer Tweakers met een PFC model te groeperen zodat de functionaliteit groeit, vooral naar HVAC is er wel nog wat (denk)werk.
Ik zal sowieso minstens één seriële klem moeten aankopen aangezien het de bedoeling is om ook DMX te gaan aansturen. Maar ik had niet voorzien dat ik ook nog een RS485 connectie zal nodig hebben voor het uitlezen van Eastron kWh meters. Dan zitten we al aan drie seriële interfaces... Kan wel eens prijzig worden.
Zal in tussentijd eens kijken wat er bij Esera beschikbaar is. Laat ons weten of je antwoord van hen krijgt betreft RS485 @MichVw.

De BeagleBOne. Je gaat die dan laten functioneren als een 1-Wire controller als ik het goed heb? Als dat goed gaat is het zeker en vast een alternatief voor de controllers van Esera. Ik heb nog ergens een samenvatting van de 1-Wire standaard liggen op pdf maar als ik me goed herinner ben ik destijds bij Esera uitgekomen omdat het 1-Wire protocol me vrij delicaat lijkt. Je moet je sensornetwerk goed uitbalanceren en bij problemen is het vaak zeer moeilijk te achterhalen waar de fout zit. Lijkt me moeilijk debuggen als je ook nog eens een eigen controller hebt. Maar, tegelijkertijd, ben ik zeer benieuwd naar je resultaten.

Ik volg je repo op Github trouwens al een tijdje. Ik heb hier reeds een testbank draaien met twee PFC200's (8202 en 8204) en ben nu bezig met het plannen van het sensornetwerk en het uitzetten van de gewenste basisfunctionaliteit. Ondertussen volg ik de ontwikkelingen met MQTT op de voet omdat deze bij mij in een tweede fase zal dienen om de andere leden van het gezin toegang te geven tot het domoticasysteem.

Ik sluit me zeker aan bij het groeperen van forumleden met PFC systemen!

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Kanze schreef op zaterdag 19 oktober 2019 @ 14:44:
[...]


Ik zal sowieso minstens één seriële klem moeten aankopen aangezien het de bedoeling is om ook DMX te gaan aansturen. Maar ik had niet voorzien dat ik ook nog een RS485 connectie zal nodig hebben voor het uitlezen van Eastron kWh meters. Dan zitten we al aan drie seriële interfaces... Kan wel eens prijzig worden.
Zal in tussentijd eens kijken wat er bij Esera beschikbaar is. Laat ons weten of je antwoord van hen krijgt betreft RS485 @MichVw.

De BeagleBOne. Je gaat die dan laten functioneren als een 1-Wire controller als ik het goed heb? Als dat goed gaat is het zeker en vast een alternatief voor de controllers van Esera. Ik heb nog ergens een samenvatting van de 1-Wire standaard liggen op pdf maar als ik me goed herinner ben ik destijds bij Esera uitgekomen omdat het 1-Wire protocol me vrij delicaat lijkt. Je moet je sensornetwerk goed uitbalanceren en bij problemen is het vaak zeer moeilijk te achterhalen waar de fout zit. Lijkt me moeilijk debuggen als je ook nog eens een eigen controller hebt. Maar, tegelijkertijd, ben ik zeer benieuwd naar je resultaten.

Ik volg je repo op Github trouwens al een tijdje. Ik heb hier reeds een testbank draaien met twee PFC200's (8202 en 8204) en ben nu bezig met het plannen van het sensornetwerk en het uitzetten van de gewenste basisfunctionaliteit. Ondertussen volg ik de ontwikkelingen met MQTT op de voet omdat deze bij mij in een tweede fase zal dienen om de andere leden van het gezin toegang te geven tot het domoticasysteem.

Ik sluit me zeker aan bij het groeperen van forumleden met PFC systemen!
Nog niets teruggehoord van Esera maar ik val ze zeker nog eens lastig :)

Klopt, BeagleBone als 1-Wire controller, als je de prijs van een BB bekijkt op Aliexpress (€50) valt dat goed mee, je hebt dan ook een controller met eMMc geheugen, dus al een stuk robuuster dan sd kaartjes. Ik dacht eraan om het als volgt aan te pakken:
- RS485 (RTU) om de onewire sensoren uit te lezen via de beaglebone. Iedere sensor heeft dan wel een harcoded register maar dat lijkt me geen ramp aangezien dit iets is die nauwelijks/nooit zal veranderen.
- de ethernet poort vande BB gebruiken voor MQTT communicatie met de sensorwaarden en implementatie van een last will en hartbeat message.

Die laatste is belangrijk om dat je dan makkelijk in OpenHab, HA, etc.. iets kan configureren die je een berichtje stuurd als ie offline gaat. Voor de prijs van de BB (in vergelijking met Esera en wago seriële klem) kan je gewoon een tweede kopen, flashen met zelfde software en klaarleggen in de kast voor als het zover is..

Error afhandeling moet ik nog eens over nadenken, eventueel zet ik statische waarden in de registers als er iets misloopt (bv. perfect 0.0 voor een temperatuur sensor en -1 voor een lichtsensor). In de software zou dan natuurlijk een effectieve 0.0 temperatuur 0.1 worden bijvoorbeeld.

Allemaal nog theoretisch, iets waar ik me volgend jaar op ga toespitsen :)

Om de 1-wire sensoren uit te lezen dacht ik om Johnny-Five te gebruiken.

Wat draait er precies op je testbanken nu? wat is het nut ervan? Stuur me gerust die pdf door van 1-Wire, ik moet nog eens goed bijlezen hoe je zo'n netwerk best bedraad en een goeie testopstelling om de setup met de BB te testen zal ook belangrijk zijn. Een paar meters kabels dus en niet 10cm naar een breadboard :)

Hoe zie je je sensornetwerk? allemaal 1-wire?

  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
MichVw schreef op maandag 21 oktober 2019 @ 10:10:
[...]


Nog niets teruggehoord van Esera maar ik val ze zeker nog eens lastig :)

Klopt, BeagleBone als 1-Wire controller, als je de prijs van een BB bekijkt op Aliexpress (€50) valt dat goed mee, je hebt dan ook een controller met eMMc geheugen, dus al een stuk robuuster dan sd kaartjes. Ik dacht eraan om het als volgt aan te pakken:
- RS485 (RTU) om de onewire sensoren uit te lezen via de beaglebone. Iedere sensor heeft dan wel een harcoded register maar dat lijkt me geen ramp aangezien dit iets is die nauwelijks/nooit zal veranderen.
- de ethernet poort vande BB gebruiken voor MQTT communicatie met de sensorwaarden en implementatie van een last will en hartbeat message.

Die laatste is belangrijk om dat je dan makkelijk in OpenHab, HA, etc.. iets kan configureren die je een berichtje stuurd als ie offline gaat. Voor de prijs van de BB (in vergelijking met Esera en wago seriële klem) kan je gewoon een tweede kopen, flashen met zelfde software en klaarleggen in de kast voor als het zover is..

Error afhandeling moet ik nog eens over nadenken, eventueel zet ik statische waarden in de registers als er iets misloopt (bv. perfect 0.0 voor een temperatuur sensor en -1 voor een lichtsensor). In de software zou dan natuurlijk een effectieve 0.0 temperatuur 0.1 worden bijvoorbeeld.

Allemaal nog theoretisch, iets waar ik me volgend jaar op ga toespitsen :)

Om de 1-wire sensoren uit te lezen dacht ik om Johnny-Five te gebruiken.

Wat draait er precies op je testbanken nu? wat is het nut ervan? Stuur me gerust die pdf door van 1-Wire, ik moet nog eens goed bijlezen hoe je zo'n netwerk best bedraad en een goeie testopstelling om de setup met de BB te testen zal ook belangrijk zijn. Een paar meters kabels dus en niet 10cm naar een breadboard :)

Hoe zie je je sensornetwerk? allemaal 1-wire?
Ben je van plan om je werk rond een implementatie van een beaglebone als 1-Wire controller te publishen op Github? Ik heb nu zelf wat meer onderzoek gedaan en het lijkt wel veelbelovend. Momenteel plan ik nog altijd een implementatie van een Esera 1-wire controller op een seriële klem op de PLC maar uiteindelijk is het uitlezen van de sensors daar ook een RS485 implementatie. Bijzonder boeiend initiatief die eigen 1-Wire controller.

De testbank ligt momenteel te wachten op de aankomst van wat nieuw materiaal. Volgende project is kijken of ik de bekende DMX302 controller betrouwbaar kan aansturen. Die zit ergens in de post. In tussentijd doe ik verder onderzoek naar de beste 1-Wire implementatie en ergens in de komende week ga ik jouw MQTT implementatie ook eens testen met een raspberry pi broker.

Betreft het sensornetwerk voorzie ik momenteel.

1. Combinatiesensor luchtvochtigheid, lichtsterkte, en temperatuur in de kamers
2. Magneetsensors op alle deuren en ramen
3. Buitenvoeler
4. Luchtkwaliteitsensors in de keuken en op de toiletten

Die zouden ideaal allemaal via 1-Wire protocol werken. Aanwezigheidsensors moet ik nog eens bekijken wat we daar voor gaan doen. Ideaal zou iets zijn dat gewoon 0-24V output geeft.

Hier is het artikel met guidelines voor betrouwbare 1-Wire netwerken.

Zelf heb ik me eerst enkele maanden ondergedompeld in IEC 61131-3 om Structured Text onder de knie te krijgen. Nu kunnen we eindelijk aan de praktische kant beginnen :)

Ik geef nog m'n repo mee met een samenvatting van structured text waar ik aan werk.

https://bitbucket.org/ntphx/iec-61131-3/src/master/

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Kanze schreef op dinsdag 22 oktober 2019 @ 10:31:
[...]


Ben je van plan om je werk rond een implementatie van een beaglebone als 1-Wire controller te publishen op Github? Ik heb nu zelf wat meer onderzoek gedaan en het lijkt wel veelbelovend. Momenteel plan ik nog altijd een implementatie van een Esera 1-wire controller op een seriële klem op de PLC maar uiteindelijk is het uitlezen van de sensors daar ook een RS485 implementatie. Bijzonder boeiend initiatief die eigen 1-Wire controller.
Ja hoor, open source approach, hoe meer mensen de implementatie gebruiken hoe betrouwbaarder ie uiteindelijk is..
Kanze schreef op dinsdag 22 oktober 2019 @ 10:31:
[...]

De testbank ligt momenteel te wachten op de aankomst van wat nieuw materiaal. Volgende project is kijken of ik de bekende DMX302 controller betrouwbaar kan aansturen. Die zit ergens in de post. In tussentijd doe ik verder onderzoek naar de beste 1-Wire implementatie en ergens in de komende week ga ik jouw MQTT implementatie ook eens testen met een raspberry pi broker.
mocht je problemen hebben laat het me zeker weten!
Kanze schreef op dinsdag 22 oktober 2019 @ 10:31:
[...]

Betreft het sensornetwerk voorzie ik momenteel.

1. Combinatiesensor luchtvochtigheid, lichtsterkte, en temperatuur in de kamers
2. Magneetsensors op alle deuren en ramen
3. Buitenvoeler
4. Luchtkwaliteitsensors in de keuken en op de toiletten

Die zouden ideaal allemaal via 1-Wire protocol werken. Aanwezigheidsensors moet ik nog eens bekijken wat we daar voor gaan doen. Ideaal zou iets zijn dat gewoon 0-24V output geeft.
laat gerust weten wat het uiteindelijk word van hardware..
Kanze schreef op dinsdag 22 oktober 2019 @ 10:31:
[...]

Zelf heb ik me eerst enkele maanden ondergedompeld in IEC 61131-3 om Structured Text onder de knie te krijgen. Nu kunnen we eindelijk aan de praktische kant beginnen :)

Ik geef nog m'n repo mee met een samenvatting van structured text waar ik aan werk.

https://bitbucket.org/ntphx/iec-61131-3/src/master/
je samenvatting word reeds vermeld in m'n getting started guide, ik wou dat ik hem had toen ik met dit alles begon ;) https://github.com/Michie.../Getting_started_guide.md

Nog even ter info: ik hoor maar niets terug van Esera in verband met een rs485 controller, reeds een aantal dagen geleden een reminder gestuurd maar geen antwoord.. Het uitblijven van een antwoord is voor mij een reden te meer om naar de beaglebone approach te gaan kijken.. Een goede support dienst geeft altijd antwoord..

  • Sandolution
  • Registratie: november 2015
  • Laatst online: 26-03 22:14
Om in te haken op zowel MQTT als sensoren door het hele huis heen, hierbij even een schets van mijn onze huidige situatie: wat hangt er in en rond het huis en hoe wordt het bestuurd?

Gezien de groeiende omvang van deze post heb ik geprobeerd de post zo duidelijk mogelijk in te richten. Dit topic leek mij de perfecte plaats om dit te posten, leek me niet nodig om hier een nieuw topic voor te maken. Vragen en/of opmerkingen? Laat het me dan weten!



Mi Casa
Wij wonen sinds juli 2018 in een huurhuis. Dit is een relatief simpel rijtjeshuis: woonkamer, keuken en berging op de begane grond, drie slaapkamers + badkamer op de eerste verdieping en een riante zolder (met mancave! *O*). Het aanleggen van allerlei bekabeling of het verbouwen van het huis was geen optie en voor een huurhuis natuurlijk ook niet rendabel. Bij het betrekken van het huis heb ik wat CAT6E kabels en aansluitingen gelegd (TV + zolder), in de plaats van de oude telefoon bedrading. Daarnaast heb ik in overleg met de verhuurders alle stopcontacten en schakelaars vervangen door degelijk Busch Jaeger schakelmateriaal (de oude konden écht niet meer). Aan verdere bedrading of leidingen heb ik niks veranderd.



Meterkast
De meterkast heeft daarintegen als enige wel een aardige metamorfose ondergaan. O-)
Onder het motto 'als je iets doet, doe het dan goed', heb ik de volledige meterkast eerst voorzien van houten platen waartegen allerhande dingen tegenaan geschroefd kunnen worden. Daarna heb ik een indeling gemaakt van de apparatuur (wat komt waar), goten gemaakt en zo stapsgewijs de meterkast gevuld. Zo zijn er in de loop van de tijd wel wat apparaten bijgekomen, maar het past nog steeds. Hieronder in twee foto's de huidige situatie geschetst, met daarbij de opsomming van de componenten die ik gebruik. Bij ieder apparaat staat ook met welke apparaat of software deze weer in verbinding staat. In principe staan alle apparaten uiteindelijk weer in verbinding met de PLC via Domoticz. Daarover meer ná de foto's. Ook heb ik zoveel mogelijk links naar externe bronnen gezet waar eventueel meer informatie te vinden is.



Meterkast - Links
Meterkast_Links

Voorgrond:
  • Server (HP Desktop, i5, 8gb ram, 1tb HDD + 120gb SSD)
    Hierop draait Proxmox (virtualisatie), met daarop virtuele machines:
    • Ares: pfSense (firewall) met een dubbele NIC PCI-e kaart
    • Hestia: Debian met Domoticz (waarschijnlijk wel bekend) en ZoneMinder (camera server)
  • APC Smart UPS 1500, verbonden met Domoticz via RS232.
    Deze houdt alle stopcontacten in de meterkast in leven bij een stroomuitval.
    Zie https://www.domoticz.com/wiki/Plugins/NUT_UPS.html
Tegen de achtermuur, van boven naar beneden:
  • Ziggo modem
  • Netgear GS108E managed switch
  • Netgear Prosafe GS108 POE Switch
Tevens noemenswaardig:
  • Osram Smart+ plug voor het schakelen van de tuinverlichting.
    Verbonden met de Hue Bridge.


Meterkast - Rechts
Meterkast_1

Linkerzijde:
  • Server + UPS, zie foto 1.
  • De originele groepenkast, waar dus niks aan verbouwd mocht worden |:(
    Bij het gebrek aan een slimme meter, heb ik daar zelf een slimme meting in gebouwd. Deze met triviale zaken als stroomverbruik, spanning, frequentie en cosphi. Vraag is hoe nauwkeurig/betrouwbaar deze is, maar het lijkt op zich vrij aardig te zijn. De meet module is via Modbus RTU (inclusief galvanische scheider) verbonden met Domoticz.
    Zie https://github.com/DomoticX/domoticz-modbus.
    Module via Ebay: https://www.ebay.com/sch/...sid=p2057872.m2749.l46251
    Daarnaast zit er op de elektra meter een oogje, die de pulsen (per wH) doorgeeft aan de PLC.
    Deze update weer een Dummy variabele in Domoticz.
  • Op de watermeter zit ook een opnemer, die ook de pulsen (per liter) naar de PLC doorstuurt.
    Ook deze update een Dummy variabele in Domoticz.
    Zie https://gathering.tweaker...message/60432588#60432588
  • De gasmeter is nog niet gelukt, deze is lastig te detecteren.
Aan de rechterzijde, van boven naar beneden:

Overigen Hardware:
Verder in het huis nog aanwezig, maar niet op foto's te vangen:
  • 2x Hue Color RGBWW lampen.
  • 2x Hue Retro lampen.
  • 3x MiLight LED RGBWW controllers t.b.v. LED-strips.
  • 1x Nefit Easy thermostaat.
    Zie https://www.domoticz.com/wiki/NefitEasy
  • 1x Google Chromecast.
    Zie https://github.com/dnpwwo/Domoticz-Google-Plugin
  • 5x Osram Smart+ Switch (+1x hierboven genoemd), voor schakelen TV, opladers, PC, etc.
    Allen verbonden met de Hue Bridge.
  • 2x Deurcontacten voordeuren, rechtstreeks op I/O van de PLC.
  • 1x KAKU AMST-606 deurcontact voor de achterdeur.
    Nu nog met RFlink, later met RFXcom.
  • 1x MiFlower plantsensor, verbonden met Domoticz via Bluetooth USB dongle.
    Zie https://github.com/flatsiedatsie/Mi_Flower_mate_plugin
  • 3x SA-33 Koppelbare Rookmelders.
    Nu nog met RFlink, later met RFXcom.
  • 1x Jenov 4k IP Camera bij voordeur, gebruikt met ZoneMinder.
  • 2x Aerohive AP121 Access Point (+1x hierboven genoemd).


Overigen Software:
Daarnaast zijn er nog wat plugins gebruikt in Domoticz:

Koppeling Domoticz <> PLC
Zoals bovenstaand uiteengezet, is eigenlijk ieder apparaat of sensor in huis wel via een of andere weg gekoppeld aan Domoticz. Echter is mijn kennis van DzVents en Lua, de programmeertalen van Domoticz, beperkt. Ik voelde er weinig voor om mij hierin compleet te verdiepen, omdat ik het gevoel had dat ik, door deze drempel, niet alles uit mijn domoticasysteem kon gaan halen wat ik zou willen. Daartegenover staat het feit dat ik in het dagelijkse leven werkzaam ben als PLC programmeur. De keuze om een PLC te gebruiken als aansturing lag dus voor de hand. Tevens zou ik zelfde PLC kunnen hergebruiken en uitbreiden, mochten wij naar een koophuis verhuizen (over een X aantal jaar). Daar kan ik hem dan gebruiken voor allerhande I/O via de PLC. Afijn, voor nu dus de koppeling met Domoticz met daarachter allerhande smarthome-apparaten.

Om te communiceren met Domoticz maak ik gebruik van zowel de HTTP API interface als de MQTT plugin. Ik heb ervoor gekozen om MQTT te gebruiken voor het continue ontvangen van updates en het zenden van commando's. Daarnaast wordt HTTP gebruikt voor het cyclisch afvragen van de status van alle variabelen zodat een eventueel gemist MQTT waarde alsnog binnen aanzienlijke tijd geüpdatet wordt.

Om dit voor elkaar te krijgen, heb ik diverse CoDeSys bibliotheken gemaakt, die samen een 'groter geheel' vormen.
  • De MQTT library voorziet een MQTT Client, waarmee een verbinding met de Mosquitto broker wordt opgezet. Dit kan met subscriben en publishen.
    Bij het ontvangen van een bericht wordt deze als complete string aan de PLC gegeven.
  • De HTTP library heeft een simpele HTTP Client die een webpagina ophaalt en deze als string aan de PLC geeft.
  • De JSON library trekt een string uit elkaar in een dubbele array van properties en waardes, waarin dan bepaalde waardes uit gefilterd kunnen worden (data)
De samenhang van alle bibliotheken is te zien in onderstaande afbeelding. Pallas is overigens de naam die ik mijn PLC toebedeeld heb :*)
Sandolution SW Overvieuw

Uiteindelijk wordt een hoop afhandeling (3000+ regels) onderhuids in het Server functieblok gedaan en blijft voor de 'gebruiker' van de bibliotheek slechts de simpele functieblokken over, die middels een connector aan elkaar hangen. Hieronder een schematisch overzicht, een overzicht van functies en ene voorbeeld functieblok.
https://tweakers.net/ext/f/Yjs6FbQyFYR0lzVrgr9gvul6/thumb.png

SNDLTN_Domoticz

SNDLTN_Domoticz Server



Fin
Mochten er mensen zijn die gebruik willen maken van een van de functieblokken (CoDeSys V3), laat het me dan even weten. Dan kan ik ze je geven en daarmee de nodige tekst en uitleg!
Ik zal over de komende dagen heen dit bericht nog een beetje uitbreiden met nog meer tekst en uitleg betreffende de bibliotheken. Maar dat heeft tijd nodig 8)7.

[Voor 69% gewijzigd door Sandolution op 31-10-2019 17:28. Reden: Content toegevoegd]


  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
Fantastische post @Sandolution! En ook altijd fijn om er beeldmateriaal bij te krijgen.

Alle informatie die je wil of kan delen over je eigen libraries en workflow met MQTT is bijzonder welkom. We proberen hier zo veel mogelijk verschillende bronnen samen te brengen.

  • yniezink
  • Registratie: juni 2010
  • Laatst online: 07-04 07:36
@MichVw ben vandaag aan de slag gegaan met je instructie op GitHub. Alles gaat goed, tot dat ik probeer mijn PLC te vinden via de netwerk scan in Codesys.

Hebben andere mensen hier ervaring mee? moet ik nog aparte zaken instellen? De runtime e.d. staat allemaal goed in de PLC (denk ik). Deze staat op codesys2 ipv eruntime.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
yniezink schreef op maandag 4 november 2019 @ 20:44:
@MichVw ben vandaag aan de slag gegaan met je instructie op GitHub. Alles gaat goed, tot dat ik probeer mijn PLC te vinden via de netwerk scan in Codesys.

Hebben andere mensen hier ervaring mee? moet ik nog aparte zaken instellen? De runtime e.d. staat allemaal goed in de PLC (denk ik). Deze staat op codesys2 ipv eruntime.
Hey yniezink,

je noemt zelf het probleem op (gelukkig :) ). Het programma is gemaakt voor CodeSys 3, instructies voor het installeren van die runtime op je PLC kan je hier vinden: YouTube: WAGO PFC200 and CoDeSys 3.5 Programming Environment

Laat maar weten mocht je nog problemen ondervinden!

  • yniezink
  • Registratie: juni 2010
  • Laatst online: 07-04 07:36
MichVw schreef op dinsdag 5 november 2019 @ 08:22:
[...]


Hey yniezink,

je noemt zelf het probleem op (gelukkig :) ). Het programma is gemaakt voor CodeSys 3, instructies voor het installeren van die runtime op je PLC kan je hier vinden: YouTube: WAGO PFC200 and CoDeSys 3.5 Programming Environment

Laat maar weten mocht je nog problemen ondervinden!
Wat dom van mij haha

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
kleine waarschuwing voor de mensen die de laatste runtime van codesys gebruiken (3.5.10.1), er zit een bug in waardoor de PLC in een faulty state komt tijdens startup, meer info hier:
https://github.com/Michie...mation.CoDeSys3/issues/19

  • thomke
  • Registratie: november 2011
  • Laatst online: 02-04 20:05
JaccoSpelt schreef op zondag 24 maart 2019 @ 11:34:
Zo, ik kom ook maar eens uit m'n meelees modus. Wij hebben een huis gekocht wat we casco op laten leveren. Genoeg uitdaging dus over hoe het in te richten. Ik ben me nu aan het richten op de elektra en aanverwanten ;).

Na het lezen van dit topic ben ik begonnen met het aanschaffen van wat spullen op eBay. Morgen komt als eerste m'n Wago PFC200 750-8212 binnen, ik heb ook een 6 tal 750-430's gekocht (6 * 8 DI) en 3 x 750-537 + 1 x 750-530 (4 * 8 DO). Hiermee heb ik de basis.

Ik ga (waarschijnlijk) schakelmateriaal van Gira (E2 vlak) gebruiken (pulsdrukkers). Achter de pulsdrukkers de bekende temperatuursensors.

Relais heb ik nog niet, mede omdat ik nog niet zo goed weet hoeveel ik er nodig ga hebben, o.a. afhankelijk van de vraag of ik de wandcontactdozen zal gaan schakelen (ik heb er nog wat discussie over met m'n vriendin..),

Ook ben ik er nog niet uit of ik met PIR's ga werken en waar ik die dan zal doen (overal of op slechts een paar plekken).

Ook over de verlichting ben ik nog flink aan het stoeien, 24v led verlichting zie ik niet zo heel veel (worden meestal met drivers erbij geleverd, goede tips?). En ook over hoe dit aan te sturen, ga ik centrale drivers plaatsen of bij elke lamp een driver en dan bijvoorbeeld 0-10V dimmen. Maar dimmen via DMX uit de PLC lijkt me ook nog wel wat.

Ik wil de sturing primair vanuit de PLC gaan doen, voor de betrouwbaarheid en ook omdat ik het goed voor kan bereiden, ik wil er tijdens de bouw niet dagen mee aan het programmeren zijn (er moet genoeg gedaan worden). Later leg ik er een laag overheen m.b.v. een Raspberry (achtig) en ik verwacht openHAB.

Wat ik volgens mij nog niet voorbij zie komen is de koppeling met beveiliging. Hebben jullie losse beveiligingssystemen er naast? Of leg je een beveiligingslaag vanuit de huisautomatisering? (wat dan vast niet gecertificeerd is, maar dat is voor mij ook geen noodzaak).

Ik blijf dit topic in ieder geval volgens en zal vast nog wel wat plaatsen.
ik ben zelf ook aan het overwegen voor de 750-8212 aan te schaffen... dit is de PFC200 2e generatie..
voordeel hiervan is dat op deze Docker geinstalleerd kan worden..

Zijn er mensen die hier ervaring mee hebben? het lijkt mij leuk om dan in docker HASS of Nodered te draaien op de plc.. Of lijkt dit jullie geen goed idee? ik ben benieuwd wat jullie hierover denken..

het valt mij ook op dat in de technical data van deze plc onder 'communication' ook 'MQTT' staat..
https://www.wago.com/be-n...troller-pfc200/p/750-8212

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
thomke schreef op dinsdag 5 november 2019 @ 22:45:
[...]


ik ben zelf ook aan het overwegen voor de 750-8212 aan te schaffen... dit is de PFC200 2e generatie..
voordeel hiervan is dat op deze Docker geinstalleerd kan worden..

Zijn er mensen die hier ervaring mee hebben? het lijkt mij leuk om dan in docker HASS of Nodered te draaien op de plc.. Of lijkt dit jullie geen goed idee? ik ben benieuwd wat jullie hierover denken..

het valt mij ook op dat in de technical data van deze plc onder 'communication' ook 'MQTT' staat..
https://www.wago.com/be-n...troller-pfc200/p/750-8212
PFC200, grote voorstander!
Docker, zeker the way to go om stabiel Domotica software te draaien!
docker op de PLC..? hmm...
- de vraag is hoeveel containers je gaat runnen? HASS is een container orchestrator dus die gaat afhankelijk van hoeveel plugins je gebruikt ook docker containers gaan opstarten.
- als je niet veel containers hebt (ik zou er zeker niet teveel draaien op de PFC), ben je er van overtuigd dat dat ook zo zal zijn in de toekomst?
- ik heb nu bijvoorbeeld: nginx, pi-hole, home assistant, grafana, influxdb, mosquitto, code-server, nodered & portainer en ben er zeker van dat daar nog containers bijkomen in de toekomst (ben je een tweaker, of niet...? ;) )
- als je gaat kijken naar het prijskaartje van de 750-8212 en de gelimiteerde resources voor Docker containers, wat zou je kunnen doen met het budget van vorig model (eerste generatie) om een computing device aan te kopen voor je docker containers te runnen?
- is het niet beter om een seperation of concerns te hebben? de kernlogica op de PLC, al de rest (waar je mee gaat tweaken) op een andere controller? Iets tweaken is tenslotte vroeg of laat iets breken ook (software mating dan).. ookal is het maar een herstart van de PLC dat je dan moet doen, ik zou het toch proberen te mijden voor je andere huisgenoten.. Reference architectuur kan je hier vinden trouwens voor dergelijke redundant setup: https://github.com/Michie...e/HomeAutomation.CoDeSys3

betreffende je MQTT opmerking, kan volgens mij twee zaken betekenen:
1. de MQTT library die Wago ter beschikking stelt (ik dacht wel dat hier een kostprijs mee gemoeid ging van €300, maar niet zeker)
2. de IoT functionaliteit in de plc (é!cockpit only functionaliteit) waarmee je events naar bv een Azure IoT hub kunt sturen adhv MQTT protocol.

  • THM0
  • Registratie: juli 2006
  • Laatst online: 13:04
Ik heb de 8212 (en een 8202). De G2 kan inderdaad Docker containers draaien, maar uiteraard heb je niet al te veel performance. Ik heb het nog niet heel uitgebreid getest overigens. Die Wago MQTT library is waarschijnlijk de Cloud Connectivity. Die is gratis en er is best wel wat over de vinden op de Wago site. Hij lijkt vooral bedoeld om te praten met public cloud IoT oplossingen (Azure IoT Hub, Amazon Greengrass, Wago's eigen cloud die ook weer draait op Azure, etc). In die hoek moet je de docker support ook zien: je kunt bijv een Azure IoT Edge image op de PLC draaien.
Het maakt ook de noodzaak om met het Board Support Package (waarmee je min of meer een eigen image kunt bouwen) veel kleiner.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
ik heb wat problemen met het uitlezen van m'n eastron sdm220.
Ik blijf maar een modbus fout krijgen: RESPONSE_CRC_FAIL, iemand een idee wat het probleem kan zijn? Volgens de docs is de checksum van de response niet correct: https://help.codesys.com/...rvModbus;version=3.5.15.0

maar ik heb geen idee hoe ik dat kan oplossen..
voor de mensen die het werkend hebben, moest hiervoor een instelling verandert worden in de web based management van de PFC (voor bijvoorbeeld de serial port als RS485 te configureren?)

EDIT: net auto-restart communication aangevinkt en nu krijg ik 'RESPONSE_TIMEOUT'. bovenstaande vraag of dat er iets dient geconfigureerd te worden en de web portal om RS485 op de serial port te gebruiken geld nog altijd :)

[Voor 16% gewijzigd door MichVw op 08-11-2019 15:36]


  • THM0
  • Registratie: juli 2006
  • Laatst online: 13:04
MichVw schreef op vrijdag 8 november 2019 @ 14:55:
ik heb wat problemen met het uitlezen van m'n eastron sdm220.
Ik blijf maar een modbus fout krijgen: RESPONSE_CRC_FAIL, iemand een idee wat het probleem kan zijn? Volgens de docs is de checksum van de response niet correct: https://help.codesys.com/...rvModbus;version=3.5.15.0

maar ik heb geen idee hoe ik dat kan oplossen..
voor de mensen die het werkend hebben, moest hiervoor een instelling verandert worden in de web based management van de PFC (voor bijvoorbeeld de serial port als RS485 te configureren?)

EDIT: net auto-restart communication aangevinkt en nu krijg ik 'RESPONSE_TIMEOUT'. bovenstaande vraag of dat er iets dient geconfigureerd te worden en de web portal om RS485 op de serial port te gebruiken geld nog altijd :)
Je moet in het web interface de poort beschikbaar stellen aan de Runtime, en vervolgens met IO Check of e!Cockpit (weet even niet helemaal zeker welke) de poort op RS485 half of full duplex instellen. Daar staat ie standaard niet op.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
THM0 schreef op zaterdag 9 november 2019 @ 17:08:
[...]

Je moet in het web interface de poort beschikbaar stellen aan de Runtime, en vervolgens met IO Check of e!Cockpit (weet even niet helemaal zeker welke) de poort op RS485 half of full duplex instellen. Daar staat ie standaard niet op.
gebruik je de codesys 3s runtime of de wago runtime? de stappen die je dient uit te voeren verschillen hoogstwaarschijnlijk..

  • THM0
  • Registratie: juli 2006
  • Laatst online: 13:04
MichVw schreef op zaterdag 9 november 2019 @ 17:10:
[...]


gebruik je de codesys 3s runtime of de wago runtime? de stappen die je dient uit te voeren verschillen hoogstwaarschijnlijk..
Wago Runtime.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Aan iedereen die gebruik maakt van 1-Wire, waarom niet gebruik maken van een kleine microchip ingewerkt in je inbouw schakelaars die RS485 aankan en daarmee temperatuur gaan uitlezen rechtstreeks in de PLC.
voordelen:
- temperatuur rechtstreeks uitlezen op PLC, geen bridge device nodig
- alle RS485 features in CodeSys: read timeouts, keep old value bij een error, etc..
- al je RS485 sensoren hebben een duidelijk adres, kan je duidelijke error afhandeling gaan doen als er plots een sensor niet meer opduikt..
- RS485 gaat tot 1200m wat zeker genoeg zou moeten zijn
- RS485 is meer bewezen in de industrie dan 1-Wire?

Ik speel nog met het idee, maar wou al eens horen of iemand een reden had om het niet te doen

  • smaertens
  • Registratie: januari 2019
  • Laatst online: 07-04 10:05
MichVw schreef op donderdag 21 november 2019 @ 10:54:
Aan iedereen die gebruik maakt van 1-Wire, waarom niet gebruik maken van een kleine microchip ingewerkt in je inbouw schakelaars die RS485 aankan en daarmee temperatuur gaan uitlezen rechtstreeks in de PLC.
voordelen:
- temperatuur rechtstreeks uitlezen op PLC, geen bridge device nodig
- alle RS485 features in CodeSys: read timeouts, keep old value bij een error, etc..
- al je RS485 sensoren hebben een duidelijk adres, kan je duidelijke error afhandeling gaan doen als er plots een sensor niet meer opduikt..
- RS485 gaat tot 1200m wat zeker genoeg zou moeten zijn
- RS485 is meer bewezen in de industrie dan 1-Wire?

Ik speel nog met het idee, maar wou al eens horen of iemand een reden had om het niet te doen
Ik ga mij daar volgend jaar ook eens mee bezig houden. Vraag die ik me wel stel, RS485, werkt dat deftig in ster? Want als je een aantal kamers uitrust met sensoren dan loopt de bekabeling wel altijd eerst naar de PLC. Je kan uiteraard van elke ster een bus gaan maken, maar je bekabeling zal dan zeer snel heel lang worden.
Ik heb er geen ervaring mee, ik vroeg het me gewoon af.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
smaertens schreef op donderdag 21 november 2019 @ 12:22:
[...]


Ik ga mij daar volgend jaar ook eens mee bezig houden. Vraag die ik me wel stel, RS485, werkt dat deftig in ster? Want als je een aantal kamers uitrust met sensoren dan loopt de bekabeling wel altijd eerst naar de PLC. Je kan uiteraard van elke ster een bus gaan maken, maar je bekabeling zal dan zeer snel heel lang worden.
Ik heb er geen ervaring mee, ik vroeg het me gewoon af.
Voor zover ik weet is het niet aangeraden om een RS485 in ster te leggen, het zou dan dus inderdaad over een bus gaan.

Als je je er mee gaat bezighouden, het ziet er naar uit dat een ATtiny85 RS485 aankan met behulp van een extra chip. Vrij interessant aangezien de ATTiny zich toch al bewezen heeft naar betrouwbaarheid en een zeer kleine vormfactor heeft: https://www.aliexpress.co...1602_3,searchweb201603_55

  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
MichVw schreef op donderdag 21 november 2019 @ 10:54:
Aan iedereen die gebruik maakt van 1-Wire, waarom niet gebruik maken van een kleine microchip ingewerkt in je inbouw schakelaars die RS485 aankan en daarmee temperatuur gaan uitlezen rechtstreeks in de PLC.
voordelen:
- temperatuur rechtstreeks uitlezen op PLC, geen bridge device nodig
- alle RS485 features in CodeSys: read timeouts, keep old value bij een error, etc..
- al je RS485 sensoren hebben een duidelijk adres, kan je duidelijke error afhandeling gaan doen als er plots een sensor niet meer opduikt..
- RS485 gaat tot 1200m wat zeker genoeg zou moeten zijn
- RS485 is meer bewezen in de industrie dan 1-Wire?

Ik speel nog met het idee, maar wou al eens horen of iemand een reden had om het niet te doen
Als we een manier kunnen vinden om de installatie te vereenvoudigen door de 1Wire controller in zijn geheel overbodig te maken ben ik zeker geïnteresseerd.

Zou het mogelijk zijn om op dezelfde chip ook sensors voor luchtvochtigheid en luminositeit te combineren?

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Kanze schreef op vrijdag 22 november 2019 @ 18:03:
[...]


Als we een manier kunnen vinden om de installatie te vereenvoudigen door de 1Wire controller in zijn geheel overbodig te maken ben ik zeker geïnteresseerd.

Zou het mogelijk zijn om op dezelfde chip ook sensors voor luchtvochtigheid en luminositeit te combineren?
met welke sensoren zou je dat doen? Ik denk wel dat de ATtiny85 genoeg pinnen heeft om meerdere sensoren te gaan uitlezen, of er genoeg geheugen is om alle sensor libraries op de ATtiny85 te krijgen das is iets anders.. Ik heb het één en het ander besteld op Aliexpress, ga me er volgend jaar mee bezig houden..

om alles te verbinden op de PCB dacht ik aan JST connectoren, het enige wat ik wel nog wat mee inzit is dat je voor ieder punt de JST connector zal moeten solderen zodat er een Cat5 kabel in toekomt en terug in vertrekt ook. Veel werk dus.. Moest er hier iemand ideetjes hebben..

moest er ook iemand ervaren zijn op het vlak van PCB design kan dat zeker nog van pas komen :)

  • Siemong
  • Registratie: september 2012
  • Laatst online: 18-02 22:58
Hey iedereen,

We gaan binnenkort bouwen en natuurlijk hoort hier wat domotica bij. Het staat al vast dat we met centrale sturing gaan werken maar ik weet nog niet goed welke PLC te gebruiken. de unipi L203 lijkt me een interessante optie maar ik ben natuurlijk op zoek naar gebruikservaringen van andere mensen.

https://www.unipi.technology/unipi-neuron-l203-p100

Raden jullie me het aan om de lichtbronnen rechtstreeks te schakelen via de relais op de PLC of eerder toch externe teleruptoren te voorzien die dan geschakeld worden door de PLC. In het eerste geval spaar ik wat geld uit maar indien de PLC faalt kan er niet meer geschakeld worden in huis :O.

Graag jullie mening

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Siemong schreef op zondag 24 november 2019 @ 11:48:
Hey iedereen,

We gaan binnenkort bouwen en natuurlijk hoort hier wat domotica bij. Het staat al vast dat we met centrale sturing gaan werken maar ik weet nog niet goed welke PLC te gebruiken. de unipi L203 lijkt me een interessante optie maar ik ben natuurlijk op zoek naar gebruikservaringen van andere mensen.

https://www.unipi.technology/unipi-neuron-l203-p100

Raden jullie me het aan om de lichtbronnen rechtstreeks te schakelen via de relais op de PLC of eerder toch externe teleruptoren te voorzien die dan geschakeld worden door de PLC. In het eerste geval spaar ik wat geld uit maar indien de PLC faalt kan er niet meer geschakeld worden in huis :O.

Graag jullie mening
Ik vind het eerlijk gezegd een prijzige PLC voor iets wat werkt met een Raspberry Pi, die dingen hebben een sdkaart met operating system en die faalt altijd vroeger of later.. hebje rs458 nodig? Anders zou ik je aanraden om op ebay.de een Wago PFC100 aan te schaffen, normaal hebje dan zelf nog budget over inputs en outputs aan te kopen..

Geen teleruptoren, zet alles op de PLC. Zeker als je voor een PFC100 gaat hebje echt een robuuste setup. Naar software voor op je PFC100 zou ik dit eens bekijken:

https://github.com/Michie...e/HomeAutomation.CoDeSys3

Die heb ik zelf geschreven, er zijn al enkele mensen die er gebruik van maken en er tevreden van zijn. Zeker een aanrader als je verder dan enkel in je PLC wilt gaan automatiseren (node-red, home-assistant, openhab, etc...)

  • J.oost
  • Registratie: juli 2013
  • Laatst online: 11:44
Beste forum-leden,

Na al meer dan een jaar stiekem meegelezen te hebben in dit topic is de tijd rijp om mij ook eens te melden hier ;)

Even een korte intro: ik heb begin dit jaar een stukje bouwgrond gekocht met de bedoeling om daarop mijn toekomstige 'droomhuis' te gaan bouwen. Ben nu volop bezig met de voorbereidende fase en een van de aspecten is het ontwerpen van de huisautomatisering.

Naast dit topic is ook het indrukwekkende filmpje van Femme een inspiratiebron geweest voor mijn huidige plan. In tegenstelling tot @Femme's idee, is mijn opzet om de kritische functies (verlichting schakelen/dimmen, verwarming aansturen, etc.) zoveel mogelijk door de PLC zelf te laten afhandelen zonder dat ik afhankelijk ben van andere protocollen of losse componenten zoals een Raspberry Pi of Arduino. Ik wil de basis dus zoveel mogelijk in CODESYS gaan programmeren en ben daarom zeer gecharmeerd van de opzet van @MichVw waarbij de essentiële taken door de PLC worden beheerd en de communicatie met externe zaken via MQTT worden gestuurd. Op dit moment is mijn kennis van MQTT nog nihil, maar ik hoop door wat te gaan experimenteren, mijn kennis op dit gebied te gaan vergroten en op termijn zelfs wat te kunnen gaan bijdragen hier :P

In eerste instantie wil ik de basisfunctionaliteiten, zoals het schakelen van stroomkringen en conventionele 230V lampen dimmen, gaan uitzoeken en implementeren om daarna randzaken zoals scènes, beveiliging, sturing van gordijnen/rolluiken, ventilatie/WTW, temperatuur-/CO2-/luchtvochtigheidsmeting, monitoren/meten van energieverbruik, aanwezigheidssimulatie, toegangscontrole, audio/tv, visualisatie, bediening via tablets/telefoons, etc. te gaan toevoegen.

De bedoeling is om zoveel mogelijk bekabeld aan te gaan leggen. Ook wil ik altijd terug kunnen gaan naar een conventionele opzet (mocht het hele domotica-plan gaan mislukken). Maar ik verwacht dat het grootste verschil met een conventioneel systeem zal zijn dat er een ster-topologie toegepast zal gaan worden in plaats van een systeem met centraaldozen.

Om een beetje gevoel te krijgen voor de voorbereidingen die bij de aanleg van een domoticasysteem komen kijken, wil ik nu alvast de PLC gaan aanschaffen zodat ik een testopstelling kan gaan bouwen om nu al wat te gaan experimenteren.

Ik heb daarvoor onderstaand lijstje in gedachten waarbij ik nog een aantal vragen heb waarvan ik hoop dat jullie deze kunnen beantwoorden:

PLC + I/O modules
• Wago Linux Starter Kit 807-099/750-8212 (https://www.wago.com/ae/p/807-099_750-8212)
- Controller PFC200 (750-8212)
- Inclusief in- en outputmodule (750-400, 750-501), 24V voeding (787-1602), eindmodule (750-600) en diverse accessoires

Dimmers 230V
• Wago 750-559 analoge uitgangsklem 0-10V 4-voudig
• Finder 15.11.8.230.0400 0-10V slave dimmer

Schakelactoren
• Wago 750-501 digitale uitgangsklem 2-voudig (meegeleverd met Starter Set)
• Finder 4C.01.9.024.0050 koppelrelais 24VDC 16A

Vraag 1: wat is het 'addertje onder het gras' bij die Wago Linux Starter Kit? Ondanks dat het natuurlijk best een smak geld is, zie ik dat een losse Wago PFC200 (750-8212) nog ongeveer €75,- duurder is dan de Starter Kit terwijl die zonder modules en accessoires wordt geleverd. Heeft dit iets te maken met de al dan niet meegeleverde software?

Als ik de topicstart van Femme goed begrepen heb is de manier zoals Wago het graag zou zien dat de PFC200 geprogrammeerd wordt met e!Cockpit (wat gebaseerd is op CODESYS 3.5). Omdat ik niet perse geïnteresseerd ben in zo'n 'fancy' ontwikkelomgeving en omdat ik een klein beetje ervaring heb met programmeren in CODESYS, wil ik de targets (is dat de goede term?) voor de PFC200 rechtstreeks bij CODESYS aanschaffen.

Vraag 2: klopt bovenstaande redenering en kan ik inderdaad de volledige functionaliteit van de Wago PFC200 750-8212 benutten (inclusief Modbus en MQTT) als ik deze gebruik in combinatie met de PFC200 targets voor CODESYS 3.5? Ik kan me voorstellen dat Wago geen ondersteuning biedt voor deze werkwijze maar blijft de garantie op het product wel gewoon behouden? Als er dingen zijn die ik wellicht mis zou ik ze graag willen horen 😉

Mochten er nog aspecten zijn die in dit vroege stadium interessant of van belang kunnen zijn dan hoor ik ze uiteraard graag. Alvast bedankt voor jullie hulp!

Joost

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
J.oost schreef op dinsdag 26 november 2019 @ 23:31:
Beste forum-leden,

Na al meer dan een jaar stiekem meegelezen te hebben in dit topic is de tijd rijp om mij ook eens te melden hier ;)

Even een korte intro: ik heb begin dit jaar een stukje bouwgrond gekocht met de bedoeling om daarop mijn toekomstige 'droomhuis' te gaan bouwen. Ben nu volop bezig met de voorbereidende fase en een van de aspecten is het ontwerpen van de huisautomatisering.

Naast dit topic is ook het indrukwekkende filmpje van Femme een inspiratiebron geweest voor mijn huidige plan. In tegenstelling tot @Femme's idee, is mijn opzet om de kritische functies (verlichting schakelen/dimmen, verwarming aansturen, etc.) zoveel mogelijk door de PLC zelf te laten afhandelen zonder dat ik afhankelijk ben van andere protocollen of losse componenten zoals een Raspberry Pi of Arduino. Ik wil de basis dus zoveel mogelijk in CODESYS gaan programmeren en ben daarom zeer gecharmeerd van de opzet van @MichVw waarbij de essentiële taken door de PLC worden beheerd en de communicatie met externe zaken via MQTT worden gestuurd. Op dit moment is mijn kennis van MQTT nog nihil, maar ik hoop door wat te gaan experimenteren, mijn kennis op dit gebied te gaan vergroten en op termijn zelfs wat te kunnen gaan bijdragen hier :P

In eerste instantie wil ik de basisfunctionaliteiten, zoals het schakelen van stroomkringen en conventionele 230V lampen dimmen, gaan uitzoeken en implementeren om daarna randzaken zoals scènes, beveiliging, sturing van gordijnen/rolluiken, ventilatie/WTW, temperatuur-/CO2-/luchtvochtigheidsmeting, monitoren/meten van energieverbruik, aanwezigheidssimulatie, toegangscontrole, audio/tv, visualisatie, bediening via tablets/telefoons, etc. te gaan toevoegen.

De bedoeling is om zoveel mogelijk bekabeld aan te gaan leggen. Ook wil ik altijd terug kunnen gaan naar een conventionele opzet (mocht het hele domotica-plan gaan mislukken). Maar ik verwacht dat het grootste verschil met een conventioneel systeem zal zijn dat er een ster-topologie toegepast zal gaan worden in plaats van een systeem met centraaldozen.

Om een beetje gevoel te krijgen voor de voorbereidingen die bij de aanleg van een domoticasysteem komen kijken, wil ik nu alvast de PLC gaan aanschaffen zodat ik een testopstelling kan gaan bouwen om nu al wat te gaan experimenteren.

Ik heb daarvoor onderstaand lijstje in gedachten waarbij ik nog een aantal vragen heb waarvan ik hoop dat jullie deze kunnen beantwoorden:

PLC + I/O modules
• Wago Linux Starter Kit 807-099/750-8212 (https://www.wago.com/ae/p/807-099_750-8212)
- Controller PFC200 (750-8212)
- Inclusief in- en outputmodule (750-400, 750-501), 24V voeding (787-1602), eindmodule (750-600) en diverse accessoires

Dimmers 230V
• Wago 750-559 analoge uitgangsklem 0-10V 4-voudig
• Finder 15.11.8.230.0400 0-10V slave dimmer

Schakelactoren
• Wago 750-501 digitale uitgangsklem 2-voudig (meegeleverd met Starter Set)
• Finder 4C.01.9.024.0050 koppelrelais 24VDC 16A

Vraag 1: wat is het 'addertje onder het gras' bij die Wago Linux Starter Kit? Ondanks dat het natuurlijk best een smak geld is, zie ik dat een losse Wago PFC200 (750-8212) nog ongeveer €75,- duurder is dan de Starter Kit terwijl die zonder modules en accessoires wordt geleverd. Heeft dit iets te maken met de al dan niet meegeleverde software?

Als ik de topicstart van Femme goed begrepen heb is de manier zoals Wago het graag zou zien dat de PFC200 geprogrammeerd wordt met e!Cockpit (wat gebaseerd is op CODESYS 3.5). Omdat ik niet perse geïnteresseerd ben in zo'n 'fancy' ontwikkelomgeving en omdat ik een klein beetje ervaring heb met programmeren in CODESYS, wil ik de targets (is dat de goede term?) voor de PFC200 rechtstreeks bij CODESYS aanschaffen.

Vraag 2: klopt bovenstaande redenering en kan ik inderdaad de volledige functionaliteit van de Wago PFC200 750-8212 benutten (inclusief Modbus en MQTT) als ik deze gebruik in combinatie met de PFC200 targets voor CODESYS 3.5? Ik kan me voorstellen dat Wago geen ondersteuning biedt voor deze werkwijze maar blijft de garantie op het product wel gewoon behouden? Als er dingen zijn die ik wellicht mis zou ik ze graag willen horen 😉

Mochten er nog aspecten zijn die in dit vroege stadium interessant of van belang kunnen zijn dan hoor ik ze uiteraard graag. Alvast bedankt voor jullie hulp!

Joost
Hey Joost!

leuk om te horen dat je gecharmeerd bent met m'n setup, ik zie uit naar je bijdrage ;)

Vraag 1: ik zou eens contact opnemen met de uitbater van de site, daar zal je meest accurate info krijgen. Ik zie alvast niet meteen een reden. Er staat ook nergens dat é!cockpit zou meegeleverd worden met licentie bij één van de twee.

Vraag 2: (hier word het interessant) voor het moment klopt je stelling dat je niets van functionaliteit gaat missen als je voor de CodeSys targets gaat. Alles wat in m'n reference project zit is gemaakt aan de hang van libraries die niet specifiek voor é!cockpit zijn. Dat gezegd zijnde heb ik vorige week een nieuwe PLC gekocht die wel de é!cockpit runtime aankan en ik moet zeggen dat ik aangenaam verrast ben door de é!cockpit omgeving. Ik overweeg dus om over te stappen naar de é!cockpit runtime. Voor alle duidelijkheid naar gevolgen toe:
- Voor de huidige componenten in m'n library zal er niets veranderen (drukknoppen, verlichting, rolluiken)
- Het is altijd mogelijk (en eenvoudig) om een é!cockpit project om te zetten naar een CoDeSys project en omgekeerd
- Reden dat ik de overstap overweeg is de é!cockpit ontwikkel omgeving (feature gewijs) maar ook de Wago libraries voor HVAC (het volgende hoofdstuk in m'n setup). Maar hier moet ik nog een Wago support contacteren om wat meer info in te winnen.
- Technische gezien dien je je een licentie aan te schaffen voor é!cockpit maar met een reinstall kan je de proefversie resetten (dacht ik, ook maar nog net geïnstalleerd)
- Ik heb al ontdekt dat de implementatie voor RS485 (om bijvoorbeeld Eastron energie meters en andere uit te lezen) zal verschillen met é!cockpit en CoDeSys maar zie geen reden waarom er niet beiden kan gesupporteerd worden in het project
- zowel CoDeSys als é!cockpit hebben een support die zeer vlot bereikbaar is
- voor de CoDeSys runtime betaal je nog eens €100 + belastingen, é!cockpit niets en als je HVAC libraries van Wago de job doen betaal je ook niets bij voor een HVAC library.

Mijn persoonlijk doel betreffende HVAC is aansturen van vloerverwarming aan de hand van zoneventielen in combinatie met sensoren die temperatuur (en misschien meer) meten per kamer. Ideaal kan ek die sensoren uitlezen via RS485 op de PLC. Hier heb ik nog wat werk om dat uit te werken.

Ik denk dat de meeste mensen hier gebruik maken van é!cockpit die m'n project gebruiken (terwijl ik eigenlijk CodeSys gebruikte maar nu ook ga omschakelen).

  • smaertens
  • Registratie: januari 2019
  • Laatst online: 07-04 10:05
Hallo Joost en Michiel

Ik ben hier ongeveer net hetzelfde aan het doen. Basis functionaliteit in de PLC de fancy extra's waarschijnlijk met openHAB of iets dergelijks via MQTT.
Ik werk met eCockpit. Daar zitten inderdaad een heleboel libraries bij onder andere de HVAC.
Michiel: als je wil weten hoe of wat wil ik je gerust wel eens laten zien wat er nu net allemaal in zit.

Joost: in verband met je verlichting die je wilt dimmen. Ik heb ook een 0-10V uitgang van Wago gebruikt maar die zit bij mij rechtstreeks op een MeanWell voeding. Mijn verlichting bestaat uit stroomgestuurde led spots. Het voordeel aan die MeanWell (vb/ MW-LCM-60) is dat ik die in de kast kan monteren en niet ergens moet ten velde gaan verstoppen of inbouwen.
De primaire kant van die voeding onderbreek ik met een eltako relais. In E-Cockpit zijn libraries met dimmers waar je eenvoudig weg een analoge uitgang aan linkt om te dimmen en een digitale output die dan de relais bekrachtigd wanneer de verlichting aan of uit moet. Als je dus naar beneden dimt en je uitgangssignaal komt op 0V zal ook de digitale uitgang er voor zorgen dat je voeding uitgezet wordt.

Ik hoop binnenkort wat meer tijd te hebben om mijn setup eens wat in beeld te brengen en ook wat bijdrage te leveren.

Michiel: in de nieuwe firmware van de Wago PFC's zit er nu standaard ook de MQTT functionaliteit in. Ik heb er enkel nog maar wat kleine testjes mee gedaan maar dat lijkt wel goed te werken.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
smaertens schreef op woensdag 27 november 2019 @ 10:04:
Hallo Joost en Michiel

Ik ben hier ongeveer net hetzelfde aan het doen. Basis functionaliteit in de PLC de fancy extra's waarschijnlijk met openHAB of iets dergelijks via MQTT.
Ik werk met eCockpit. Daar zitten inderdaad een heleboel libraries bij onder andere de HVAC.
Michiel: als je wil weten hoe of wat wil ik je gerust wel eens laten zien wat er nu net allemaal in zit.

Joost: in verband met je verlichting die je wilt dimmen. Ik heb ook een 0-10V uitgang van Wago gebruikt maar die zit bij mij rechtstreeks op een MeanWell voeding. Mijn verlichting bestaat uit stroomgestuurde led spots. Het voordeel aan die MeanWell (vb/ MW-LCM-60) is dat ik die in de kast kan monteren en niet ergens moet ten velde gaan verstoppen of inbouwen.
De primaire kant van die voeding onderbreek ik met een eltako relais. In E-Cockpit zijn libraries met dimmers waar je eenvoudig weg een analoge uitgang aan linkt om te dimmen en een digitale output die dan de relais bekrachtigd wanneer de verlichting aan of uit moet. Als je dus naar beneden dimt en je uitgangssignaal komt op 0V zal ook de digitale uitgang er voor zorgen dat je voeding uitgezet wordt.

Ik hoop binnenkort wat meer tijd te hebben om mijn setup eens wat in beeld te brengen en ook wat bijdrage te leveren.

Michiel: in de nieuwe firmware van de Wago PFC's zit er nu standaard ook de MQTT functionaliteit in. Ik heb er enkel nog maar wat kleine testjes mee gedaan maar dat lijkt wel goed te werken.
Hey,

zeker interesse!
Het is misschien een idee om een telegram channel aan te maken op de git repo om concreter te babbelen over HVAC, MQTT, CoDeSys, é!cockpit development? Of je nu het project gebruikt of niet, ervaringen wisselen blijft zeer waardevol. (ik kijk er deze week voor)

Ik ga ook een paar git issues maken voor HVAC om alles wat meer in beeld te brengen. Voor alle duidelijkheid: HVAC is v2 milestone, de v1 nu (verlichting en drukknoppen) is af en werkt prima :)

  • J.oost
  • Registratie: juli 2013
  • Laatst online: 11:44
Dank voor jullie uitgebreide antwoorden! Veel kennis aanwezig hier merk ik. Leuk ook om te lezen dat meerdere mensen met een vergelijkbare setup bezig zijn.

Wat betreft het (prijs-) verschil tussen de losse PLC en de Starter Kit zal ik inderdaad eens contact opnemen met de betreffende webshop.

Er is al veel over geschreven maar ik merk dat ik nog steeds niet helemaal begrijp wat nu het praktische verschil is tussen e!Cockpit en CODESYS 3.5 (in combinatie met de PFC200 target). MichVw, begrijp ik het goed dat de belangrijkste reden voor het switchen naar e!Cockpit is dat dit pakket standaard is voorzien van een aantal libraries voor bijvoorbeeld HVAC? Op de website van CODESYS vind ik bijvoorbeeld ook libraries voor CODESYS 3.5 (al dan niet betaald). Wat is dan echt de toegevoegde waarde van het gebruik van e!Cockpit? De reden voor deze vraag is dat ik begrepen heb dat een e!Cockpit licensie erg duur is (maar wat het nou echt kost kan ik nergens terugvinden...). Hoe komen jullie hier dan aan? Las dat de goedkoopste optie om zo'n licentie te verkrijgen is door een Wago Starter Kit PFC100 aan te schaffen. Is dit dan ook de set die jullie hebt gekocht of hebben jullie een losse licentie aangeschaft?

Maar aangezien de Wago PFC100 kit aanzienlijk duurder is dan de PFC200 kit (zelfs als ik de aanschaf van de CODESYS PFC200 targets meereken) neig ik er nog steeds naar om de PFC200 kit aan te schaffen. Maar als er goede argumenten zijn om toch een andere keus te maken dan hoor ik ze graag. Vind het geen probleem om een eenmalige grote investering te doen maar wil voorkomen dat ik (bij wijze van spreken) over 2 jaar wederom zo'n bedrag moet uitgeven.

Ik begrijp dat voor jou e!Cockpit ook nog redelijk nieuw is MichVw, dus ben benieuwd wat jouw ervaringen hiermee zijn de komende tijd. Meten van de temperatuur per kamer en aansturen van vloerverwarming met zoneventielen is trouwens precies wat ik ook wil gaan doen. Ik ga je project met interesse volgen ;)
smaertens schreef op woensdag 27 november 2019 @ 10:04:
Joost: in verband met je verlichting die je wilt dimmen. Ik heb ook een 0-10V uitgang van Wago gebruikt maar die zit bij mij rechtstreeks op een MeanWell voeding. Mijn verlichting bestaat uit stroomgestuurde led spots. Het voordeel aan die MeanWell (vb/ MW-LCM-60) is dat ik die in de kast kan monteren en niet ergens moet ten velde gaan verstoppen of inbouwen.
De primaire kant van die voeding onderbreek ik met een eltako relais. In E-Cockpit zijn libraries met dimmers waar je eenvoudig weg een analoge uitgang aan linkt om te dimmen en een digitale output die dan de relais bekrachtigd wanneer de verlichting aan of uit moet. Als je dus naar beneden dimt en je uitgangssignaal komt op 0V zal ook de digitale uitgang er voor zorgen dat je voeding uitgezet wordt.
Bedankt voor je suggestie en uitleg smaertens! Heb me eigenlijk nog niet echt verdiept in welk type verlichting ik wil gaan gebruiken, maar wil zo min mogelijk met losse trafo's gaan werken eigenlijk. In verband met prijs en verkrijgbaarheid wil ik in principe vooral 'conventionele' 230V verlichting gaan gebruiken (E27, GU10 spotjes). Maar alles is nog mogelijk dus hoor het graag als ik wat ruimdenkender moet zijn op dit gebied ;)
smaertens schreef op woensdag 27 november 2019 @ 10:04:
Michiel: in de nieuwe firmware van de Wago PFC's zit er nu standaard ook de MQTT functionaliteit in. Ik heb er enkel nog maar wat kleine testjes mee gedaan maar dat lijkt wel goed te werken.
Hoe moet ik dit precies zien? Is dit een hardware-functionaliteit of bedoel je dat de MQTT functionaliteit nu standaard in e!Cockpit zit ingebouwd? Is de MQTT library van stefandreyer dan geen vereiste meer?

Jullie merken dat ik nog heel veel vragen heb :X Maar ik hoop dat ik met jullie adviezen een juiste keus kan maken voor de aanschaf van een PLC zodat ik wat praktijkervaring op kan gaan doen en hopelijk in de toekomst hier ook wat bij te kunnen gaan dragen O-)

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
J.oost schreef op woensdag 27 november 2019 @ 22:59:
Wat betreft het (prijs-) verschil tussen de losse PLC en de Starter Kit zal ik inderdaad eens contact opnemen met de betreffende webshop.
laat zeker iets weten!
J.oost schreef op woensdag 27 november 2019 @ 22:59:
Er is al veel over geschreven maar ik merk dat ik nog steeds niet helemaal begrijp wat nu het praktische verschil is tussen e!Cockpit en CODESYS 3.5 (in combinatie met de PFC200 target). MichVw, begrijp ik het goed dat de belangrijkste reden voor het switchen naar e!Cockpit is dat dit pakket standaard is voorzien van een aantal libraries voor bijvoorbeeld HVAC? Op de website van CODESYS vind ik bijvoorbeeld ook libraries voor CODESYS 3.5 (al dan niet betaald). Wat is dan echt de toegevoegde waarde van het gebruik van e!Cockpit? De reden voor deze vraag is dat ik begrepen heb dat een e!Cockpit licensie erg duur is (maar wat het nou echt kost kan ik nergens terugvinden...). Hoe komen jullie hier dan aan? Las dat de goedkoopste optie om zo'n licentie te verkrijgen is door een Wago Starter Kit PFC100 aan te schaffen. Is dit dan ook de set die jullie hebt gekocht of hebben jullie een losse licentie aangeschaft?
Ik denk dat iedereen hier werkt met de proefperiode en een reinstall om deze te resetten, een licentie is inderdaad duur (€800 dacht ik), mocht die dus in een starterpakket zitten hoor ik het graag en vooral welke versie het (voor één of meerdere devices)
Ik begrijp dat de keuze voor é!cockpit niet helemaal te verantwoorden valt, vooral door het licentie gedoe. Zelf vind ik het ook een ambetante kwestie waar ik vaak nog wat twijfels bij heb.. Geef gerust je mening.
J.oost schreef op woensdag 27 november 2019 @ 22:59:
Maar aangezien de Wago PFC100 kit aanzienlijk duurder is dan de PFC200 kit (zelfs als ik de aanschaf van de CODESYS PFC200 targets meereken) neig ik er nog steeds naar om de PFC200 kit aan te schaffen. Maar als er goede argumenten zijn om toch een andere keus te maken dan hoor ik ze graag. Vind het geen probleem om een eenmalige grote investering te doen maar wil voorkomen dat ik (bij wijze van spreken) over 2 jaar wederom zo'n bedrag moet uitgeven.
Ga zeker voor een PFC200, de PFC100 lijn ken ik niet zo goed maar die heeft voor zover ik weet geen RS485 en dat is een mooie meerwaarde om van die Eastron energie meters te gaan uitlezen (en meer).
J.oost schreef op woensdag 27 november 2019 @ 22:59:
Ik begrijp dat voor jou e!Cockpit ook nog redelijk nieuw is MichVw, dus ben benieuwd wat jouw ervaringen hiermee zijn de komende tijd. Meten van de temperatuur per kamer en aansturen van vloerverwarming met zoneventielen is trouwens precies wat ik ook wil gaan doen. Ik ga je project met interesse volgen ;)
Top! @Kanze , heb jij ook als doel om HVAC in je PLC te gaan steken? indien dat het geval is moeten we de koppen gaan samen steken zodat we kiezen voor zelfde runtime (CoDeSys of é!cockpit)
J.oost schreef op woensdag 27 november 2019 @ 22:59:

Hoe moet ik dit precies zien? Is dit een hardware-functionaliteit of bedoel je dat de MQTT functionaliteit nu standaard in e!Cockpit zit ingebouwd? Is de MQTT library van stefandreyer dan geen vereiste meer?
De Wago MQTT library kan je enkel gebruiken op de é!cockpit runtime, de library van stefandreyer op é!cockpit en CoDeSys, de lib van Stefan werkt zeer goed maar bij Wago heb je natuurlijk support (nu en in de toekomst). Stel dat we kiezen om é!cockpit te gebruiken maar een licentie aan te schaffen tot dat uiteindelijk echt moet en we komen op een prijs van €800/pp moet je daar bij rekenen dat daarin een officiële libraries zitten voor json/hvac/mqtt als je daar dan nog eens de runtime licentie van CoDeSys bijtelt begin je in de buurt te komen... Maar het is en blijft veel geld!

Ik ben bijna klaar met een v1.0.0 van m'n project en maak binnenkort een release! (eindelijk :) )

  • dries_47
  • Registratie: januari 2014
  • Laatst online: 08:22
Dag iedereen

Anderhalf jaar geleden stuitte ik toevallig op dit bijzonder interessante forum. Ik was destijds op zoek naar een bouwgrond om een nieuwe woning op te trekken. In afwachting van de ideale locatie besloot ik me alvast te verdiepen in hoe ik mijn denkbeeldige droomwoning kon automatiseren.

Na ook andere mogelijkheden zoals oa Loxone en KNX overwogen te hebben raakte ik na het lezen op het forum (en uiteraard ook “Smarthome kooptips voor de doe-het-zelver” en “het slimste huis in de Achterhoek”) meer en meer overtuigd van een robuuste PLC gebaseerde oplossing.

Toen ik ook in aanraking kwam met MQTT begon de puzzel in elkaar te vallen en besloot ik een Wago e!Cockpit-Starterkit met PFC100 Controller 750-8100 aan te schaffen. De voordelen die ik hierin zag waren de “moderne” 8100 controller en door Wago ondersteunde software en libraries. De maanden nadien hield ik Ebay in de gaten op zoek naar goede I/O deals. Daarna bouwde ik een test-setup om de tips vanop het forum te kunnen onderzoeken.

Andere voorbereiding voor het bouwproces verdrongen het geëxperimenteer naar de achtergrond, maar op dit moment buigen de abtenaren van de stedenbouwkundige dienst buigen zich intussen over mijn bouwaanvraag dus moeten er knopen doorgehakt worden over wat het gaat worden.

Ik ben het idee genegen om de sterkte van een PLC optimaal te benutten door deze waar mogelijk de logica te laten afhandelen voor basistaken zoals verlichting, rolluiken en aansturen van stelventielen voor vloerverwarming. Daarnaast zullen ook deur/raamcontacten, bewegingsdetectie en temperatuursensoren geïntegreerd worden.

Gezien ik zelf op software vlak nog geen grote stappen gezet heb, en qua architectuur nagenoeg het zelfde plan lijk te hebben volg ik het werk van MichVw met bijzondere aandacht. Ik ben er intussen in geslaagd om het project aan de praat te krijgen in e!Cockpit met mijn eigen proefopstelling en ben onder de indruk van de overzichtelijke code en goede documentatie.

Qua front end heb ik mijn eieren voorlopig in de Home Assistant-mand gelegd, die draai ik in Docker op Synology (net zoals een MQTT broker).

Ik ben tot hier toe in de luwte gebleven omdat ik het idee heb dat ik minder technisch ben dan de gemiddelde gebruiker hier, en niet het gevoel had veel te kunnen bijdragen. Mocht ik echter iemand vooruit kunnen helpen door iets te testen in e!Cockpit dan wil ik gerust een poging doen.

Dries

  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
J.oost schreef op dinsdag 26 november 2019 @ 23:31:
Vraag 1: wat is het 'addertje onder het gras' bij die Wago Linux Starter Kit? Ondanks dat het natuurlijk best een smak geld is, zie ik dat een losse Wago PFC200 (750-8212) nog ongeveer €75,- duurder is dan de Starter Kit terwijl die zonder modules en accessoires wordt geleverd. Heeft dit iets te maken met de al dan niet meegeleverde software?

Als ik de topicstart van Femme goed begrepen heb is de manier zoals Wago het graag zou zien dat de PFC200 geprogrammeerd wordt met e!Cockpit (wat gebaseerd is op CODESYS 3.5). Omdat ik niet perse geïnteresseerd ben in zo'n 'fancy' ontwikkelomgeving en omdat ik een klein beetje ervaring heb met programmeren in CODESYS, wil ik de targets (is dat de goede term?) voor de PFC200 rechtstreeks bij CODESYS aanschaffen.
Het prijsverschil ontstaat omdat PLC's eigenlijk producten voor de industrie zijn maar de starterkit bedoeld is voor de consumentenmarkt. In de starterkit zitten wat extra dingen plus een e!cockpit licentie. Dat lijkt onlogisch want je krijgt bij de starterkit meer waar voor je geld en toch is het goedkoper. Zo werkt de bedrijfswereld nu eenmaal.

@MichVw @J.oost @smaertens

Ik heb contact opgenomen met de Belgische tak van WAGO en daar gesproken met een support engineer over het gebruik van PLC's in kleine particuliere installaties zoals de onze.

Tussen de lijnen liet deze man me verstaan dat het eigenlijk niet nodig is om een licentie aan te kopen voor e!cockpit als consument.. De huidige versies van e!cockpit werken met een ingebouwde vervaldatum van 30 gebruiksdagen dus geen kalenderdagen. Na het vervallen van die proefperiode blijft de PLC runtime gewoon doorwerken met het programma dat is geprogrammeerd. Het volstaat dus om e!cockpit te installeren in een virtual machine op je computer. Als je proefperiode voorbij is zet je die virtual machine even terug naar een snapshot en je hebt weer 30 gebruiksdagen. Nogmaals; zelfs als je gebruiksdagen in e!cockpit zijn vervallen werkt de PLC gewoon door. Ik heb dit voor jullie getest en dit klopt. Dit zeggen dat het gebruik van e!cockpit (momenteel) dus de facto gratis is.

Voor mensen die willen starten met een PLC raad ik deze methode aan in combinatie me de aankoop van een 2dehands PFC200. Je kan een 8202 krijgen op eBay voor 300 euro. Als je dan geen licentiekosten hebt en gebruik maakt van een eenvoudige Meanwell voeding ben je een stuk goedkoper af als met de starterkit.

Het is niet uit te sluiten dat WAGO uiteindelijk beslist om deze manier van werken voor de consument af te sluiten. Maar de versies van e!cockpit die momenteel bestaan laten het toe en zullen dus ook altijd blijven werken op deze manier. Gezien de extreme maturiteit van het platform en de hardware lijkt me dit dus een verantwoorde manier van werken voor een consument ook op de lange termijn. Wat toch belangrijk is voor een domoticaproject.

Ik heb dan ook besloten om met de e!cockpit runtime te gaan werken en mijn testbank draait nu drie maanden op deze manier zonder problemen. Mij lijkt dit voor projecten van onze grootte de juiste weg vooruit - wat denken jullie?
MichVw schreef op vrijdag 29 november 2019 @ 12:51:

Top! @Kanze , heb jij ook als doel om HVAC in je PLC te gaan steken? indien dat het geval is moeten we de koppen gaan samen steken zodat we kiezen voor zelfde runtime (CoDeSys of é!cockpit)
Absoluut! De eerstkomende week heb ik het bijzonder druk op het werk maar nadien stort ik me weer volop op het PLC project. Onze bouw loopt momenteel al met de aanzet van de ruwbouw dus ik zal in deze redelijk snel keuzes moeten beginnen maken op vlak van HVAC technieken.

Als jullie willen kan ik hier gaandeweg wel een bouwdagboek uitzetten eenmaal we aan de elektriciteit en de domotica komen. De theorie zit wel allemaal mooi in mijn hoofd maar in de praktijk wilt het wel eens anders uitpakken in de bouw heb ik al gemerkt :)

  • J.oost
  • Registratie: juli 2013
  • Laatst online: 11:44
@MichVw @Kanze
Bedankt voor jullie uitgebreide antwoord, erg verhelderend! Ik begrijp dat e!Cockpit de meest gebruikte manier is om de Wago PLC’s te programmeren (enerzijds via een licentie uit een Starter Kit, anderzijds met een demo die om de 30 dagen hernieuwd wordt). De ‘kale’ CODESYS optie i.c.m. de PFC200 targets is een andere optie, maar dan zijn de e!Cockpit Wago libraries dus niet beschikbaar.

Ik concludeer dat ik met de PLC die ik op het oog heb beide kanten opkan, dus ik denk dat ik voor de de eerder genoemde PFC200 Starter Kit ga. Voor nu is dat de meest economische optie om mee te beginnen en op basis van de verhalen die ik hier en daar lees (zoals de optie om de Eastron energiemeters via RS485 te kunnen gebruiken en communicatie via MQTT) denk ik dat deze keus aardig ‘future-proof’ is.

Ondanks dat er inmiddels veel duidelijk is geworden heb ik nog steeds heel veel vragen, maar ik denk dat ik gewoon maar eens moet gaan beginnen en kijken waar het schip gaat stranden (want dat zal ongetwijfeld gaan gebeuren :P). Maar genoeg expertise hier in ieder geval om het schip weer vlot te trekken ;)

@dries_47
Interessant om te lezen dat jij ook met een nieuwbouwproject bezig bent en ook voor de PLC gebaseerde domotica-architectuur gaat! Het lijkt er inderdaad op dat wij (net zoals MichVw) dezelfde opzet hebben; de essentiële taken door de PLC laten afhandelen en de communicatie van niet-essentiële processen via MQTT laten verlopen. Ik lees dat jij inmiddels al wat verder bent maar ik hoop dus binnenkort ook met een test-opstelling te kunnen gaan beginnen. Zal mijn ervaringen zeker gaan delen hier.
Kanze schreef op zondag 1 december 2019 @ 09:42:
Absoluut! De eerstkomende week heb ik het bijzonder druk op het werk maar nadien stort ik me weer volop op het PLC project. Onze bouw loopt momenteel al met de aanzet van de ruwbouw dus ik zal in deze redelijk snel keuzes moeten beginnen maken op vlak van HVAC technieken.

Als jullie willen kan ik hier gaandeweg wel een bouwdagboek uitzetten eenmaal we aan de elektriciteit en de domotica komen. De theorie zit wel allemaal mooi in mijn hoofd maar in de praktijk wilt het wel eens anders uitpakken in de bouw heb ik al gemerkt :)
Bij jou begint het dus echt al wat concreter te worden, leuk! Lijkt me erg leerzaam en interessant om te lezen welke praktische uitdagingen je tegen gaat komen tijdens de bouw, dus zo’n dagboek zou zeer gewaardeerd worden! _/-\o_

  • sjoerd1980
  • Registratie: januari 2002
  • Laatst online: 27-03 22:01
Bij deze meld ik me ook even in dit topic. Gisteren de Linux starterkit besteld om ermee te kunnen spelen voor gebruik in onze nieuwe woning.

In eerste instantie ga ik er alleen verlichting mee sturen (pulsdrukkers naar relais toe), later uitgebreid met dimmers (Dali / DMX nog tbd)

Maar op kort termijn wil ik er ook verwarming mee gaan sturen. Op dit moment heb ik de bron voor mijn warmtepomp nog niet werkend, maar wil ik wel de het elektrische verwarmingselement gaan gebruiken om de vloer op temperatuur te krijgen. Ik denk dat de warmtepomp dit zelf niet kan (natuurlijk wil deze in eerste instantie de compressor gebruiken), dus wil ik het verwarmingselement en de circulatiepomp door de PLC laten sturen en natuurlijk met terugkoppeling van watertemperatuur en eventueel later ruimtetemperatuur.

De temperatuursensoren van de warmtepomp moet ik nog nader bekijken (welk type het betreft). Voor de ruimtesensoren heb ik voor elke ruimte een TelAire Airestat 5001 liggen. Dit is een CO2 sensor met temperatuursensor erin. De CO2 sensor geeft 0-10V uit, dus deze kan op een normale analoge ingang. Maar de temperatuursensor is een 20k NTC.

Nu heeft WAGO een klem voor zulke sensoren (uiteraard tegen een flink bedrag) en ik verwacht dat het tweedehands aanbod niet overweldigend zal zijn. Heeft iemand ervaring met het gebruik van dergelijke sensoren?

Enkele plannen voor de PLC voor later;
- Sturen van de ventilatie (WTW). Bijvoorbeeld niet afzuigen als de afzuigkap actief is, niet inblazen als er brandalarm is... En betreffende ruimte / zone niet inblazen als het raam open staat.
- Monitoren van de elektriciteit en watermeter en van de PV inverter.
- Sturen van de vloerverwarming (zones) en waar nodig de warmtepomp zelf.
- Licht aan in geval van brandalarm.

Bedrading in huis heb ik per verdieping naar een regelkast. Daarin komt dan de boel samen en gaat er een kabel naar de andere regelkast(en). En uiteraard naar de meterkast.

Aan de onderzijde van de kast komt er zowel 230V als de lagere spanningen binnen (24V van de pulsdrukkers, signaal van de CO2/temp sensors, raamcontacten etc.). Hoe houden julie die in de kast gescheiden? Mijn idee is om bijv. alle 230V tegen de muur in te laten komen en dan onder de eerste klemmenrij door te laten lopen. De rest komt dan op de 1e rij klemmen welke wat hoger moet liggen. Maar hoe dat praktisch gerealiseerd moet worden weet ik nog niet. Tips zijn dan ook zeker welkom.

Bovenin de kast gaat dat later misschien ook wel spelen (wanneer er LED drivers in de kast geplaatst gaan worden), maar vooralsnog is dat allemaal 230V.

Alvast bedankt! Als ik wat kan laten zien, iets verder in het proces, zal ik dat zeker doen.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
Zeeeer leuk om te horen dat er zoveel interesse is en er de wil is om samen te gaan werken aan een implementatie!

Wat ik zou voorstellen:
v1.1: conversie naar é!cockpit first approach (samen te bespreken)
v1.2: RS485 support, mogelijkheid om Eastron smd energiemeters te gaan uitlezen en ook via zelfde implementatie temperatuursensoren voor HVAC (ingewerkt in lichtschakelaars)
v2.0: HVAC!
• Aansturen zoneventielen aan de hand van temperatuursensoren
• Aansturen pomp warmtepomp (ik heb een famillielid die bij Vaillant werkt waar ik wel wat info kan vragen)
• Webvisu implementatie in de PLC om verwarming (alle bovenstaande puntjes dus) aan te sturen via html5. De hele setup moet robuust zijn dus lijkt me belangrijk om dit ook rechtstreeks op de PLC te kunnen aansturen?

Om concreet verder te gaan zou ik onderstaande voorstellen:
- Iedereen die interesse heeft om m'n project te gaan gebruiken, graag een github account aanmaken als je die nog niet hebt en de gitter chat joinen (link, ook te bereiken door op de gitter badge te drukken in de readme op de git repo)
- Laat weten wat je mening is met betreffing tot de codesys/é!cockpit keuze
- Laat weten of de funcionaliteit in de v2.0 voldoet aan jou doeleinden, indien niet, laat weten wat je mist van functionaliteit
- Laat weten wat je deadline is
- Laat weten of je wilt/tijd hebt om bij te dragen

Met de gitter wil ik de mensen die er gebruik van maken groeperen op een medium gelinkt aan de gitrepo met een lage comminicatiegrens (lijkt me niet onbelangrijk).

Indien je niet kan bijdragen: zeker geen probleem! Hoe meer mensen gebruik maken van de setup hoe beter! Bugs worden rapper ontdekt en alles word veel rapper zoals het hoort!

Nog even voor alle duidelijkheid: dit is de link naar de git repo: https://github.com/Michie...e/HomeAutomation.CoDeSys3

Indien mogelijk graag engels als voertaal voor git issues en de gitter chat?

Ik tag ook even een paar mensen; @arjan_1980 , @Kanze , @J.oost , @sjoerd1980 , @dries_47 , @smaertens, @yniezink , @thomke , @THM0 , @mpdevries84 , @TailwindNL , @Heire , @ThePsycho , @Fraggar

[Voor 3% gewijzigd door MichVw op 02-12-2019 08:57]


  • TailwindNL
  • Registratie: april 2008
  • Laatst online: 27-02 20:05
@MichVw Even een sneller reactie:

Allereerst: Goed initiatief!

Voor het punt van v1.1: Ik heb heb al draaien op e!cockpit. Stukje conversie gedaan, maar dat stelde niet zoveel voor. De vraag is of je meer voor ogen hebt, maar in basis is het dus makkelijk naar e!cockpit te brengen.

Ik heb tot nu toe alleen geëxperimenteerd met DMX en dimmen van GU10 230V leds, i.c.m. drukkers via digitale inputs op de WAGO en mqtt via jouw project.

Wat ik nog mis (tenzij ik het over het hoofd heb gezien), zijn RGB/sterkte waarden. Ik zou bijvoorbeeld via MQTT een dimwaarde (0-100 of 0-255) willen sturen en de PLC dit laten verwerken en doorvoeren in de output. En visa versa --> de huidige waarde van een dimmer via MQTT willen monitoren via een subscribe.

Wat ook handig zou zijn is om een soort van "Virtual Devices" te implementeren. Dit ken ik van HomeSeer (Loxone kent iets vergelijkbaars wat zij noemen "Virtual Inputs"). In essentie is dit vanuit de PLC niets meer dan een variabele met een waarde, die gevuld/veranderd kan worden vanuit de PLC code en middels MQTT. Op deze manier krijg je een bi-directionele werking tussen de PLC en andere apparaten/domotica controllers middels MQTT op een universele manier.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
TailwindNL schreef op maandag 2 december 2019 @ 09:11:
@MichVw Even een sneller reactie:

Allereerst: Goed initiatief!

Voor het punt van v1.1: Ik heb heb al draaien op e!cockpit. Stukje conversie gedaan, maar dat stelde niet zoveel voor. De vraag is of je meer voor ogen hebt, maar in basis is het dus makkelijk naar e!cockpit te brengen.
klopt zeker, het is niet veel werk! ik wil gewoon even afvinken of iedereen hem kan vinden in de keuze voor é!cockpit. Documentatie (getting started guide) moet er ook bij aangepast worden
TailwindNL schreef op maandag 2 december 2019 @ 09:11:
Wat ik nog mis (tenzij ik het over het hoofd heb gezien), zijn RGB/sterkte waarden. Ik zou bijvoorbeeld via MQTT een dimwaarde (0-100 of 0-255) willen sturen en de PLC dit laten verwerken en doorvoeren in de output. En visa versa --> de huidige waarde van een dimmer via MQTT willen monitoren via een subscribe.
klopt ook helemaal, er is geen FB_OUTPUT_DIMMER_MQTT omdat ik geen analoge output heb liggen om te testen. Als ik er echter nu wat meer bij nadenk zou dat eigenlijk geen probleem mogen zijn om zonder te doen. Als je een git issue aanmaakt op de repo kijk ik ervoor, ben je bereid om te testen als ik iets gemaakt heb?
TailwindNL schreef op maandag 2 december 2019 @ 09:11:
Wat ook handig zou zijn is om een soort van "Virtual Devices" te implementeren. Dit ken ik van HomeSeer (Loxone kent iets vergelijkbaars wat zij noemen "Virtual Inputs"). In essentie is dit vanuit de PLC niets meer dan een variabele met een waarde, die gevuld/veranderd kan worden vanuit de PLC code en middels MQTT. Op deze manier krijg je een bi-directionele werking tussen de PLC en andere apparaten/domotica controllers middels MQTT op een universele manier.
Hoewel ik geen ervaring heb met HomeSeer of Loxone denk ik te begrijpen waar je naartoe wilt. Ik denk ook dat het reeds het geval is voor de FB_OUTPUT_SWITCH_MQTT.

Bv: als die output high word (door toggle input, prio high input, ...) komt er een TRUE event op:
WAGO-PFC200/Out/DigitalOutputs/FB_NAME
om de output vanuit MQTT aan te sturen:
WAGO-PFC200/In/DigitalOutputs/FB_NAME
dan heb je toch een bi-directionele werking tussen de PLC en andere aan de hand van een soort 'MQTT virtuele waarde'?

  • TailwindNL
  • Registratie: april 2008
  • Laatst online: 27-02 20:05
MichVw schreef op maandag 2 december 2019 @ 10:10:
[...]
klopt zeker, het is niet veel werk! ik wil gewoon even afvinken of iedereen hem kan vinden in de keuze voor é!cockpit. Documentatie (getting started guide) moet er ook bij aangepast worden
Check! Ik ben voor e!cockpit (met name vanwege het feit dat DMX te gebruiken is via de RS323/485 module en de wago libraries).
[...]
klopt ook helemaal, er is geen FB_OUTPUT_DIMMER_MQTT omdat ik geen analoge output heb liggen om te testen. Als ik er echter nu wat meer bij nadenk zou dat eigenlijk geen probleem mogen zijn om zonder te doen. Als je een git issue aanmaakt op de repo kijk ik ervoor, ben je bereid om te testen als ik iets gemaakt heb?
[...]
Ja hoor.
Hoewel ik geen ervaring heb met HomeSeer of Loxone denk ik te begrijpen waar je naartoe wilt. Ik denk ook dat het reeds het geval is voor de FB_OUTPUT_SWITCH_MQTT.

Bv: als die output high word (door toggle input, prio high input, ...) komt er een TRUE event op:
WAGO-PFC200/Out/DigitalOutputs/FB_NAME
om de output vanuit MQTT aan te sturen:
WAGO-PFC200/In/DigitalOutputs/FB_NAME
dan heb je toch een bi-directionele werking tussen de PLC en andere aan de hand van een soort 'MQTT virtuele waarde'?
Ja klopt, maar dit is nog beperkt tot de zaken die jij nu specifiek beschikbaar hebt gemaakt. Met een virtual device wordt het mogelijk gemaakt om een willekeurige waarde te publishen/subscriben (in een paar varianten conform variabeletypen (boolean, string, etc.)). Hieronder wat voorbeelden van de Virtual Device / Virtual Input:

https://forums.homeseer.c...creation-and-modification

https://www.loxone.com/enen/kb/virtual-inputs-outputs/

Mijn Catgenie monitoring oplossing die gebruik maakt van virtual devices in Homeseer:
https://www.domoticaforum...ic.php?f=17&t=5024#p40121

Als ik dit doorvertaal naar een implementatie dan is het, het automatisch (of gecontroleerd dmv een functie aanroep) publishen van de variabelewaarden naar de MQTT broker bij wijzigingen. En het ontvangen van data (boolean, string, etc.) via een MQTT subscribe naar de PLC. Het verschil is dat dit universeel is en niet vast hangt aan specifieke functieblokken.

Hopelijk maak ik hiermee duidelijker wat ik bedoel.

  • MichVw
  • Registratie: mei 2017
  • Laatst online: 12:53
TailwindNL schreef op maandag 2 december 2019 @ 15:07:
Ja klopt, maar dit is nog beperkt tot de zaken die jij nu specifiek beschikbaar hebt gemaakt. Met een virtual device wordt het mogelijk gemaakt om een willekeurige waarde te publishen/subscriben (in een paar varianten conform variabeletypen (boolean, string, etc.)). Hieronder wat voorbeelden van de Virtual Device / Virtual Input:

https://forums.homeseer.c...creation-and-modification

https://www.loxone.com/enen/kb/virtual-inputs-outputs/

Mijn Catgenie monitoring oplossing die gebruik maakt van virtual devices in Homeseer:
https://www.domoticaforum...ic.php?f=17&t=5024#p40121

Als ik dit doorvertaal naar een implementatie dan is het, het automatisch (of gecontroleerd dmv een functie aanroep) publishen van de variabelewaarden naar de MQTT broker bij wijzigingen. En het ontvangen van data (boolean, string, etc.) via een MQTT subscribe naar de PLC. Het verschil is dat dit universeel is en niet vast hangt aan specifieke functieblokken.

Hopelijk maak ik hiermee duidelijker wat ik bedoel.
ik begrijp wat bedoelt en lijkt me zeker interessant. Het enige wat ik er aan wil toevoegen:
- PLC sotware is strongly typed, dus er zal een FB zijn per type. bv FB_VIRTUAL_INT_MQTT, FB_VIRTUAL_STRING_MQTT, etc...
- bij implementatie zorg ik ervoor dat er opties zijn de waarde te gaan bijhouden doorheen power cycles en of de waarde dient gepublished te worden bij startup

maak hier gerust een git issue voor op de repo (graag een andere issue dan de dimmer output), dan kijk ik ervoor.

leuke feedback :)

  • Rein_stein
  • Registratie: maart 2003
  • Laatst online: 07-04 21:32
Ik heb sinds een half jaar een PLC draaien van Scheider, de M221 (Type: TM221CE40T). Dat ding heeft een ethernet aansluiting (programmeren vanaf de bank, helemaal top), 24 inputs, 16 outputs en de ontwikkelomgeving is gratis. Ze zijn ook wat goedkoper dan de WAGO PLCs maar er is nauwelijks tweedehands spul voor te vinden. Tot nu toe draait het overigens zonder problemen.

Setup:
* Verschillende puls drukkers (Gira 55 series) door het huis heen verbonden met de PLC (24v) via el-cheapo ethernet kabels
* Lampen die aan/uit kunnen worden geschakeld vanaf de PLC via Finder 4C.01.9.024.0050 relais
* Om LED lampen te dimmen gebruik ik de PWM outputs (hij heeft er helaas maar 2) en Eltako LUD12-230V vermogensdimmers die PWM input hebben. Via PWM aansturen werkt best heel mooi, helaas heeft de PLC maar 2 PWM outputs en zijn ze niet als uitbreidingsmodules te kopen.

Schema's op de PLC:
* aan-uit schakelaars: 1x drukken aan, nog eens drukken uit
* dimmers: 1x drukken aan, nog eens drukken uit, ingedrukt houden om een dim cyclus te starten en die wordt vastgezet zodra je weer los laat.

Alles werkt zowel stand-alone als via Home Assistant. Het is redelijk makkelijk om daar schakelaars en dimmers in toe te voegen en er vervolgens automatiseringen op los te laten (buitenverlichting aan bij zonsondergang etc).

Momenteel doe ik de 'kritische' infrastructuur (lichtschakelaars) via de PLC en lees ik overige sensoren (temperatuur, luchtvochtigheid en PIR) uit via MQTT met NodeMCUs om de kosten een beetje te drukken. Die NodeMCUs zijn erg goedkoop en stabiel genoeg voor sensoren.

  • Kanze
  • Registratie: juli 2019
  • Laatst online: 12:19
Rein_stein schreef op maandag 2 december 2019 @ 21:47:
Ik heb sinds een half jaar een PLC draaien van Scheider, de M221 (Type: TM221CE40T). Dat ding heeft een ethernet aansluiting (programmeren vanaf de bank, helemaal top), 24 inputs, 16 outputs en de ontwikkelomgeving is gratis. Ze zijn ook wat goedkoper dan de WAGO PLCs maar er is nauwelijks tweedehands spul voor te vinden. Tot nu toe draait het overigens zonder problemen.

Setup:
* Verschillende puls drukkers (Gira 55 series) door het huis heen verbonden met de PLC (24v) via el-cheapo ethernet kabels
* Lampen die aan/uit kunnen worden geschakeld vanaf de PLC via Finder 4C.01.9.024.0050 relais
* Om LED lampen te dimmen gebruik ik de PWM outputs (hij heeft er helaas maar 2) en Eltako LUD12-230V vermogensdimmers die PWM input hebben. Via PWM aansturen werkt best heel mooi, helaas heeft de PLC maar 2 PWM outputs en zijn ze niet als uitbreidingsmodules te kopen.

Schema's op de PLC:
* aan-uit schakelaars: 1x drukken aan, nog eens drukken uit
* dimmers: 1x drukken aan, nog eens drukken uit, ingedrukt houden om een dim cyclus te starten en die wordt vastgezet zodra je weer los laat.

Alles werkt zowel stand-alone als via Home Assistant. Het is redelijk makkelijk om daar schakelaars en dimmers in toe te voegen en er vervolgens automatiseringen op los te laten (buitenverlichting aan bij zonsondergang etc).

Momenteel doe ik de 'kritische' infrastructuur (lichtschakelaars) via de PLC en lees ik overige sensoren (temperatuur, luchtvochtigheid en PIR) uit via MQTT met NodeMCUs om de kosten een beetje te drukken. Die NodeMCUs zijn erg goedkoop en stabiel genoeg voor sensoren.
Kan je een beetje meer uitweiden over welke sensors je gebruikt en hoe je setup werkt met NodeMCU's?

  • joostboot
  • Registratie: september 2013
  • Laatst online: 17-03 17:43
Hallo allemaal,

Ik meld me ook aan! Ondertussen lees ik ook al een tijdje stiekem mee en heb zelfs al een aardige systeemkast geïnstalleerd staan in onze technische ruimte. Deze bevat o.a. een pfc100 starterskit plus een boel extra io-modules, KNX/ArtNet, esera 1-wire en Home Assistant, noem maar op.

Door de nieuwbouwwoning heen liggen SVV kabels naar alle schakelpunten (behalve de wc die per abuis alleen pvc naar de centraaldoos heeft). Ook is elke ruimte verwarmd met een eigen vloerverwarmingszone. Dat was eigenlijk ook de hoofdreden om voor een zelfbouw domotica systeem te gaan omdat het gewoon stukken goedkoper (en leuker) dan commerciële alternatieven. De woning bevat veel glas en daarom ligt ook alles al klaar om t.z.t. ook de zonnewering aan te gaan sturen met de PLC om zo wat gratis verwarming binnen te krijgen of natuurlijk juist buiten te houden..

Momenteel is nog lang niet alles aangesloten maar heb ik al wel een testsetup draaien waarmee ik in ieder geval alles met homeassistant/nodered (via MQTT, dank voor de library!) aan elkaar kan knopen. Zo draait ArtNet voor de verlichting momenteel als een custom component van homeassistant en heb ik een nodered programmaatje draaien die de temperatuursensors vanaf de esera hub naar homeassistant brengt, welke vervolgens met de PLC aanstuurt om een klep te openen of te sluiten.

Om alles wat robuuster te maken wil ik langzaam alle kritieke onderdelen dus nog esera 1-wire, ArtNet óf DMX, HVAC inclusief zonnewering integreren in de PLC. Nog genoeg te doen dus.

  • thomke
  • Registratie: november 2011
  • Laatst online: 02-04 20:05
@MichVw ,
Ik ben nog steeds geintreseerd, heb net ook een PFC200 aangeschaft maar nog geen tijd gehad om er mee te spelen. voorlopig zal ik nog weinig kunnen bijdragen (we zijn net begonnen met de ruwbouw waar ik aan mee help waardoor ik maar zeer weinig tijd over heb) eenmaal de technieken er liggen zal ik ook beginnen spelen met de PLC.


Mijn bedoeling is vooral om zo veel mogelijk op een hoger liggend niveau te regelen (HASS + NodeRed of IpSymcon). dan is mijn bedoelin om wanneer de communicatie weg valt met de hoger liggende software terug te vallen op 'domme' PLC logica..


Verder moet ik ook nog de mogelijkheden van de RS485 poort op de plc bekijken..

ik ben vanplan veel 1-wire sensoren te voorzien, ik zou deze eventueel via deze poort ook binnen nemen op de plc..
Verder vroeg ik mij ook af als de PLC met ART-NET kan communiceren voor DMX drivers.. heeft iemand als zoiets gedaan?

ook hier dacht ik anders weer de DMX vanuit hoger liggende software aan te sturen.. indien de communicatie weg valt.. dat dan de PLC begint te zenden over ART-Net naar de DMX modules..

Mensen die hier bedenkingen/tips voor hebben? of die reeds zoiets gedaan hebben? :)

Bedankt!

  • J.oost
  • Registratie: juli 2013
  • Laatst online: 11:44
MichVw schreef op vrijdag 29 november 2019 @ 12:51:
[...]
laat zeker iets weten!
[...]
Heb inmiddels contact opgenomen met InSystems-Shop en heb een aantal antwoorden gekregen die voor jullie wellicht ook interessant kunnen zijn.

Antwoord op de vraag of de Wago Linux-STARTERKIT 807-099 / 750-8212 mit WAGO CONTROLLER PFC200 een e!Cockpit licentie bevat (net zoals de Wago Starterkit für PFC100 Controller 750-8100):
Das Linux-StarterKit enthält keine e!Cockpit Lizenz und kann über Linux programmieret werden. Der Controller 750-8212 lässt sich sowohl über eCockpit als auch über CoDeSys programmieren.
E!Cockpit Lizenz 2759-101/1110-2002 ist das kleinste Lizenz Model. Diese muss separat erworben werden.
Samengevat: de Linux StarterKit met de PFC200 bevat dus geen e!Cockpit licentie.

Antwoord op de vraag waardoor de kit met de PFC200 goedkoper is dan een losse controller en of er verschillen zijn tussen de controller uit de kit en de losse versie:
Technisch kein Unterschied. Beim StarterKit handelt es sich um einen durch WAGO subventionierten Preis um den Kunden den ersten Step mit dem System zu erleichtern. Abgabemenge pro Endkunde ist auf ein StarterKit begrenzt.
Samengevat: geen technische verschillen tussen de controller uit de kit en de losse variant. Prijsverschil heeft ermee te maken dat Wago de set in de markt zet als een prijsgunstige manier om vertrouwd te raken met hun systeem. Eigenlijk wat @Kanze dus ook al schetste.

Inmiddels heb ik de Wago Linux StarterKit met de PFC200 besteld. Zal volgende week binnenkomen dus ben benieuwd :)
MichVw schreef op maandag 2 december 2019 @ 08:14:
Om concreet verder te gaan zou ik onderstaande voorstellen:
- Iedereen die interesse heeft om m'n project te gaan gebruiken, graag een github account aanmaken als je die nog niet hebt en de gitter chat joinen (link, ook te bereiken door op de gitter badge te drukken in de readme op de git repo)
- Laat weten wat je mening is met betreffing tot de codesys/é!cockpit keuze
- Laat weten of de funcionaliteit in de v2.0 voldoet aan jou doeleinden, indien niet, laat weten wat je mist van functionaliteit
- Laat weten wat je deadline is
- Laat weten of je wilt/tijd hebt om bij te dragen

Met de gitter wil ik de mensen die er gebruik van maken groeperen op een medium gelinkt aan de gitrepo met een lage comminicatiegrens (lijkt me niet onbelangrijk).
Goed idee! Zal binnenkort een GitHub account aanmaken en de chat joinen. Ik zie dat er inmiddels al een interessante discussie is ontstaan daar. Op zich prima om op die plek de technische details van jouw HomeAutomation project te bespreken maar zou het wel jammer vinden als de algemene ‘PLC voor domotica’ discussie zich daarheen zou verplaatsen. Ik denk namelijk dat er hier op het forum heel veel kennis aanwezig is die wellicht niet direct met PLC’s te maken heeft maar wel zeer interessant kan zijn voor huisautomatisering en - elektra in het algemeen.

Wat betreft de keuze tussen e!Cockpit en CODESYS: ik ga in eerste instantie met CODESYS aan de gang. De reden om niet (meteen) met e!Cockpit te starten is dat CODESYS platform-onafhankelijk is, de standaard binnen de industrie is (zo lijkt het tenminste), de ontwikkelsoftware gratis is (behalve de targets en eventueel benodigde libraries). Ook het risico dat de ‘truc’ met het verlengen van een e!Cockpit licentie op den duur een halt toegeroepen wordt vind ik gevaarlijk, er is daarmee een kans dat we veel gebruikers verliezen.

Ik ga nu dus eerst met CODESYS aan de gang met de bedoeling om alles aan de praat te krijgen zonder daar e!Cockpit voor nodig te hebben. Maar als ik wat vertrouwder begin te raken met de materie sluit ik zeker niet uit dat ik in de toekomst ook eens ga kijken wat e!Cockpit wellicht kan toevoegen. Ik zou het echter wel jammer vinden als het HomeAutomation project van @MichVw ‘e!Cockpit only’ zou worden (in de zin dat er een afhankelijkheid van e!Cockpit libraries zou ontstaan).

Wat betreft de rest van je voorstellen zit ik nog in een zodanig stadium dat het nog te vroeg is om hier iets zinnigs over te zeggen. Mijn deadline is sowieso nog lang niet in zicht, maar de bedoeling is er zeker om in de toekomst mijn input te gaan leveren! ;)
Pagina: 1 ... 8 ... 11 Laatste


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True