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 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]
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
Het is dus zo dat horizontaal een omgeving tot 60°C toelaat, maar verticaal slechts 40°C
Edit: net even opgezocht
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 ]
/u/109256/crop55f85a5bb3ef0_cropped.png?f=community)
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.
:strip_icc():strip_exif()/u/550330/crop5db6b73bee53e_cropped.jpeg?f=community)
:
[...]
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
ID.3 Pro 58 kWh | Ede | 5740 Wp | PVOutput
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.
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!
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!
Voor mijn hvac regeling gebruik ik deze modules. https://nl.aliexpress.com...1602_5,searchweb201603_52:
[...]
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!
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
Dat ziet er wel interessant uit. Makkelijk te installeren en programmeren? Heb je daarvoor nog aparte software nodig om dat te programmeren?:
[...]
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.
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::
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!
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 ]
Ik probeer het komende week te bekijken en ga dan meteen ook eens e!cockpit proberen:
[...]
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 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?
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?
[ Voor 34% gewijzigd door VBP8501 op 29-09-2019 13:45 ]
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.:
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?
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 ]
De firmware kun je uitlezen met I/O Check:
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?
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:
Firmware 06 kan ook DMX berichten ontvangen/uitlezen.
[ Voor 14% gewijzigd door THM0 op 29-09-2019 14:47 ]
Allez ik heb v6, daar heb ik dan wel geluk gehad.[b]
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.
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.:
[...]
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
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 ]
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...:
[...]
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
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
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.:
[...]
Zijn het nu de ledjes of de driver... Ik had ze liever in serie aangesloten maar dan kan ik niet genoeg spanning geven..
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 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 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 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?
:strip_exif()/u/89037/crop561ba346ae6b0.gif?f=community)
Die library ziet er inderdaad zeer interessant uit! is die €90 per device?:
[...]
'basis' is misschien wat teveel voor interpretatie vatbaar
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?
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.
/u/1/femme.png?f=community)
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?
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:
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?
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.
[ Voor 27% gewijzigd door mpdevries84 op 15-10-2019 20:38 ]
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
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 😐:
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
Veel succes ermee alvast!
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.
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
:strip_exif()/u/113667/ja-man.gif?f=community)
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.
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
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 ]
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.:
[...]
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.
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?
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.:
[...]
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?
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/
Ja hoor, open source approach, hoe meer mensen de implementatie gebruiken hoe betrouwbaarder ie uiteindelijk is..
mocht je problemen hebben laat het me zeker weten!
laat gerust weten wat het uiteindelijk word van hardware..
je samenvatting word reeds vermeld in m'n getting started guide, ik wou dat ik hem had toen ik met dit alles begon:
[...]
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/
https://github.com/Michie.../Getting_started_guide.mdNog 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..
/u/709893/crop5cf4c7e648cde_cropped.png?f=community)
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!
). 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.
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
Voorgrond:
Meterkast - Rechts
Linkerzijde:
Overigen Hardware:
Verder in het huis nog aanwezig, maar niet op foto's te vangen:
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.
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.
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
.
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!
). 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.
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
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
- Ziggo modem
- Netgear GS108E managed switch
- Netgear Prosafe GS108 POE Switch
- Osram Smart+ plug voor het schakelen van de tuinverlichting.
Verbonden met de Hue Bridge.
Meterkast - Rechts
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.
- Hue Bridge, standaard integratie in Domoticz.
Zie https://www.domoticz.com/wiki/Philips_Hue_Lights - Aerohive AP121 Access Point
- Thalassa behuizing, momenteel met:
- MiLight Bridge, verbonden via WiFi. Standaard integratie in Domoticz.
Zie https://www.domoticz.com/wiki/Limitless/AppLamp_LED - RFlink, verboden met Domoticz via USB.
Zie https://www.domoticz.com/wiki/RFLink
Wordt in de nabije toekomst vervangen door RFXcom. - ESP8266 MySensors Gateway, verbonden via WiFi.
Deze is niet gekoppeld aan Domoticz, maar rechtstreeks aan de PLC via MQTT.
Zie https://www.mysensors.org/build/esp8266_gateway - Voedingen 3.3V en 5V
- MiLight Bridge, verbonden via WiFi. Standaard integratie in Domoticz.
- Weidmuller 24V 10A voeding
- Lenze 3200C PLC (CoDeSys V3) met een handjevol I/O eraan. Dit vormt het 'hart' van het huis en bestuurd alles. Daarover verderop meer.
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:
- SystemAliveChecker > Alle apparaten met Ethernet/WiFi worden continue gepingt.
Zo weet ik exact of kritieke infrastructuur faalt, en wie en wat er thuis zijn.
Zie https://www.domoticz.com/wiki/System_Alive_Checker_(Ping) - Buienalarm voor korte termijn voorspelling
Zie https://github.com/Xorfor/Domoticz-Buienalarm-Plugin - Buienradar met extra weersvoorspelling voor de komende dagen.
Zie https://github.com/Sandolution/domoticz-buienradar - Speedtest voor bewaking up-/download + ping
Zie https://github.com/Xorfor/Domoticz-Speedtest-Plugin - Motherboard sensors, default plugin 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)
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.
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
.
[ Voor 69% gewijzigd door Sandolution op 31-10-2019 17:28 . Reden: Content toegevoegd ]
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 EnvironmentLaat maar weten mocht je nog problemen ondervinden!
Wat dom van mij haha:
[...]
Hey yniezink,
je noemt zelf het probleem op (gelukkig
Laat maar weten mocht je nog problemen ondervinden!
ik ben zelf ook aan het overwegen voor de 750-8212 aan te schaffen... dit is de PFC200 2e generatie..:
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.
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.
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
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 ]
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.:
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
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
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
.
Graag jullie mening
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
.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..:
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
Graag jullie mening
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...)
/u/527875/tweakers_avatar3.png?f=community){kind=avatar}
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
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
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
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!:
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
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
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).
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
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
Jullie merken dat ik nog heel veel vragen heb
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
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
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
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
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
laat zeker iets weten!
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.
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).
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):
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
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
)
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?
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
@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). 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.
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
). 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.
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!:
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
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
@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!
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!
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):
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:
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
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!