Domotica met plc's

[BoschR]

Oke, ik ben enthousiast. Voornamelijk dankzei de video bij Femme thuis .

Voorheen scrolde ik de bedrade domotica topics vaak voorbij, maar bij nader inzien is het wel erg gaaf. Al zal ik op dit moment niet mn huis overhoop gaan halen om een stervormige installatie aan te leggen. Oriënteren en een proef opstelling lijkt me mooi om mee te beginnen.

Momenteel heb ik al wel redelijk wat draadloze domotica: Domoticz op een NAS draaien en milights (+/- 15), zwave (6 nodes, alles plus), p1, RFLink, MQTT (broker draait op een RPi), PVOutput, IP camera en nog wat klein spul. Daarnaast nog een Arduino Solar meter voor PVOutput voor de zonnepalen en verbruik.

Wat betreft de PLC wereld is alles nieuw voor mij en het is wel erg veel. Afgelopen dagen/avonden heb ik me proberen te verdiepen in de materie door het doorlezen van dit topic, youtube en andere artikelen op het internet. Ik moet zeggen dat ik dit een erg goed artikel vind. Maar verder gaat het er moeizaam in en ik weet van mijzelf dat ik het beste leer uit de praktijk (net als o.a. bij mijn huidige setup). Grote bottleneck in het verhaal is ook wel het ontbreken van basis elektronica kennis.

Mijn (eerste) vraag is eigenlijk wat jullie adviseren om snel een leuke stap te kunnen maken in het ontdekken. Ik begrijp dat voornamelijk de WAGO plc erg populair is en dan met name de PFC200 (750-8204). Daarnaast ook de Loxone en de Siemens logo. +/- 700 euro voor een PLC (PFC200) om wat mee te spelen zonder serieuze plannen in dit huis is duur speelgoed.

Bij de keuze voor een PLC waar moet ik op letten en selecteren. Ik zie dat er erg veel verschillende modellen zijn. Aantal UTP sockets? RS485? RS232? Ik kwam bijvoorbeeld deze logo starterskit tegen. Ik kan zelf alleen niet bepalen wat hieraan "mist".

Wat wil ik ermee is dan waarschijnlijk de eerste vraag. In eerste instantie meer basiskennis opdoen (Digitale vs analoge in-/outputs, Modbus (RTU?), rijgklemmen, etalageklemmen, 1wire, relais, dmx, etc).

[Femme]

BoschR schreef op woensdag 26 april 2017 @ 20:08:
Oke, ik ben enthousiast. Voornamelijk dankzei de video bij Femme thuis .

Voorheen scrolde ik de bedrade domotica topics vaak voorbij, maar bij nader inzien is het wel erg gaaf. Al zal ik op dit moment niet mn huis overhoop gaan halen om een stervormige installatie aan te leggen. Oriënteren en een proef opstelling lijkt me mooi om mee te beginnen.

Momenteel heb ik al wel redelijk wat draadloze domotica: Domoticz op een NAS draaien en milights (+/- 15), zwave (6 nodes, alles plus), p1, RFLink, MQTT (broker draait op een RPi), PVOutput, IP camera en nog wat klein spul. Daarnaast nog een Arduino Solar meter voor PVOutput voor de zonnepalen en verbruik.

Wat betreft de PLC wereld is alles nieuw voor mij en het is wel erg veel. Afgelopen dagen/avonden heb ik me proberen te verdiepen in de materie door het doorlezen van dit topic, youtube en andere artikelen op het internet. Ik moet zeggen dat ik dit een erg goed artikel vind. Maar verder gaat het er moeizaam in en ik weet van mijzelf dat ik het beste leer uit de praktijk (net als o.a. bij mijn huidige setup). Grote bottleneck in het verhaal is ook wel het ontbreken van basis elektronica kennis.

Mijn (eerste) vraag is eigenlijk wat jullie adviseren om snel een leuke stap te kunnen maken in het ontdekken. Ik begrijp dat voornamelijk de WAGO plc erg populair is en dan met name de PFC200 (750-8204). Daarnaast ook de Loxone en de Siemens logo. +/- 700 euro voor een PLC (PFC200) om wat mee te spelen zonder serieuze plannen in dit huis is duur speelgoed.

Bij de keuze voor een PLC waar moet ik op letten en selecteren. Ik zie dat er erg veel verschillende modellen zijn. Aantal UTP sockets? RS485? RS232? Ik kwam bijvoorbeeld deze logo starterskit tegen. Ik kan zelf alleen niet bepalen wat hieraan "mist".

Wat wil ik ermee is dan waarschijnlijk de eerste vraag. In eerste instantie meer basiskennis opdoen (Digitale vs analoge in-/outputs, Modbus (RTU?), rijgklemmen, etalageklemmen, 1wire, relais, dmx, etc).

Je kunt ook overweg om een goedkope Chinese kloon van een Mitsubische plc te gebruiken voor I/O, bijvoorbeeld de EX1S 30MR met zestien inputs en veertien 5A relais van nog geen 52 dollar. Je hangt 'm met een rs-485 usb-stick aan je Raspberry Pi en dan kun je via Modbus RTU de ingangen uitlezen en relais aansturen. Er is ook een variant met transistoruitgangen waar je losse 24V relais mee kunt bekrachtigen (identiek aan een Wago digitale outputmodule). Er zijn ook versies met analoge ingangen en uitgangen. Je kunt ze ook programmeren via Mitsubishi GX Developer 8.5 maar daar heb ik nog geen ervaring mee. Dit is wel een leuke en betaalbare manier om aan de slag te gaan met bedrade domotica.

Met een Wago weet je zeker dat je een betrouwbare oplossing in handen hebt en wat ik ook erg mooi vindt is dat het systeem super modulair is en er een groot assortiment aan I/O-modules is.

endness schreef op vrijdag 28 april 2017 @ 13:56:
@DP Kunst Hoe ga jij 't aanpakken met de software? Ik zie de 750-881 inderdaad voorbij komen voor leuke prijzen, maar zit toch een beetje met de software. Ik kwam dit filmpje tegen waarmee je volgens mij via een Raspberry de waardes van de Wago uit kunt lezen. Een licentie voor de Pi zou 30 euro kosten. Is dat wellicht een goede oplossing?

Ik denk dat je dan beter gewoon domoticasoftware zoals IP-Symcon of Home Assistant op de RPi kunt draaien waarmee je de Wago via modbus kunt aansturen en uitlezen. Je kunt dan makkelijker allerlei andere hardware zoals Philips Hue-lampen en z-wave spul integreren, je kunt makkelijker acties laten plaatsvinden bij bepaalde events, data loggen en het hele zaakje op afstand via een app bedienbaar maken en visualiseren.

[jellevictoor]

Ik heb de boel uiteindelijk werkend gekregen. Ik ben geen zo'n fan van de delay alsook niet van het posten van berichten via http naar mijn openhab. Daarom heb ik een mqtt lib gezocht (en gevonden! https://github.com/FieldFox/Codesys-Mqtt-lib). Met deze ga ik dus geen modbus gebruiken voor signalen te ontvangen, maar signalen sturen bij het indrukken van een knop naar mijn mqtt bus en deze uitlezen.
Geen idee of dit zal werken bij het lang ingedrukt houden van een knop, maar ik ben nog niet in die fase. Ik hou jullie op de hoogte

Edit: een mqtt bericht sturen van de wago naar een topic is kinderspel, nog mensen die dit doen?

[ Voor 8% gewijzigd door jellevictoor op 05-06-2017 19:36 ]

[MichVw]

jellevictoor schreef op zondag 4 juni 2017 @ 09:56:
Ik heb de boel uiteindelijk werkend gekregen. Ik ben geen zo'n fan van de delay alsook niet van het posten van berichten via http naar mijn openhab. Daarom heb ik een mqtt lib gezocht (en gevonden! https://github.com/FieldFox/Codesys-Mqtt-lib). Met deze ga ik dus geen modbus gebruiken voor signalen te ontvangen, maar signalen sturen bij het indrukken van een knop naar mijn mqtt bus en deze uitlezen.
Geen idee of dit zal werken bij het lang ingedrukt houden van een knop, maar ik ben nog niet in die fase. Ik hou jullie op de hoogte

Edit: een mqtt bericht sturen van de wago naar een topic is kinderspel, nog mensen die dit doen?

Geen ervaring mee, het ziet er inderdaad simpel uit. Heb je een idee naar performantie toe? hoelang duurt het sturen van een simpele waarde naar een topic? Het is een eventueel een simpele optie om het Modbus polling systeem te vervangen en event driven te werken wat performanter zou moeten zijn.

ik ben nu al eventjes info aan het opzoeken om tcp/udp te gebruiken naar een C# applicatie. heeft iemand hier ervaring mee of voorbeeld code?

[jellevictoor]

Als ik nu enkele milliseconden een knop ingedurkt hou, heb ik 64 berichten verstuurd, geen overhead.
Ik wil mijn outputs schrijven via modbus en mijn input triggers via mqtt

Ik heb toch heel wat moeite gehad om modbus goed te snappen, meteen de configuratie doen in openhab is een brug te ver. Ik kan deze documentatie (voor wago) erg aanraden en ook deze tool (qmodmaster)

Voor de mensen waarvoor dit totaal nieuw is, hier komt het op neer (wanneer je modbus wil gaan gebruiken). Je rasberrypi (of waar je je software op draait) is je modbus master en je gaat je modbus slave (plc) gaan pollen. Je plc heeft een aantal inputs en outputs. Je hebt verschillende functie codes die je via het modbus protcol kan gaan sturen. In het geval van simpele DI en DO is dit F1 (read) en F5 (write). Mits dit Digitale modules zijn, heb je enkel binaire statusen (0 & 1).

Een belangrijke opmerking is dat het nodig is om effectief permissions te geven aan je outputs dat deze via modbus mogen geschreven worden.

Dan moet je nog opzoeken vanaf waar je addressen beginnen te tellen, bij de wago plc is dit vanaf 0 voor de DI's, de DO's beginnen vanaf 512.

Het lukt me nu dus om via mqtt een bericht te sturen wanneer een DI hoog is en een DO aan te schakelen via qmodmaster.

Next up: dit allemaal via een switch in openhab krijgen

edit: outputs schrijven vanuit openhab lukt nu ook. Erg simpel eens je modbus snapt. Uitlezen lukt nog niet, maar ik vang dit op met mqtt

[ Voor 83% gewijzigd door jellevictoor op 05-06-2017 22:36 ]

[jellevictoor]

Ik heb nu ook wat code om effectief enkel maar een mqtt bericht te sturen eens een knop ingedrukt is, wanneer je deze loslaat stuur ik een off bericht. Works like a charm.
Als mensen ook de PLC code willen, ik kan deze wel makkelijk op github gooien, ik wil er een functie van maken zodat ik dit makkelijk kan koppelen aan iedere input die een knop is, maar daarvoor moet ik me wat meer verdiepen in de plc code.

Ik merk met OpenHab dat ik het probleem niet heb zoals hier beschreven dat modbus een signaal niet oppikt zonder delay. Ligt dit dan aan de polling van ip-symcon?

[jellevictoor]

ondertussen heb ik het niet meer voor gehad dat de PLC faalt bij het starten. Wanneer ik het opnieuw voor heb, ga ik dit proberen, thanks!

Ondertussen heb ik een generieke button geschreven die een mqtt genereerd en dat dan naar een topic stuurt op mijn PLC. Op die manier kan ik effectief pushen vanop mijn PLC.
Ik vroeg me af of er hier iemand enorm bedreven is in het schrijven van PLC software die mijn code even wil reviewen? Ik ben zelf programmeur, maar dit is compleet nieuw voor mij en vind geen zo'n grote online community. Ik ben hier dus wat aan het spelen met bestaande libs die ik mash tot een geheel.

Wat me enorm stoort aan deze code is dat het MQTT stuk aan het eind van de cycle moet. Wanneer ik dit niet doe, stuurt de PLC geen berichten en crashed de ganse IDE. Vandaar kan ik per cycle maar 1 bericht schrijven. In praktijk werkt het wel lekker, de cycles van de wago zijn zo snel, dat dit geen verschil maakt

code: PLC_PRG

PROGRAM PLC_PRG
VAR
    input_001 AT %IX0.0: BOOL;
    input_002 AT %IX0.1: BOOL;
    input_003 AT %IX0.2: BOOL;
    input_004 AT %IX0.3: BOOL;

    button_001: BUTTON;
    button_002: BUTTON;
    button_003: BUTTON;
    button_004: BUTTON;

    button_time: TIME:=t#600ms;

    pub:BOOL;
    subi:BOOL;
    payload:STRING;
    topic:STRING;
    mqttClient: MQTT_Client;
END_VAR

pub:=FALSE;
subi:=FALSE;
payload:='';
IF NOT pub THEN
    topic:='dev/switch/1';
    button_001(IN:=input_001, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/2';
    button_002(IN:=input_002, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/3';
    button_003(IN:=input_003, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/4';
    button_004(IN:=input_004, PT:=button_time, pub=>pub, payload=>payload);
END_IF

mqttClient(
    sTopic:= topic,
    sPayload:= payload ,
    sIp:= IP ,
    wPortNumber:= PORT ,
    sUsername:= USERNAME ,
    sPassword:= PASS,
    xPublish:= pub ,
    xSubscribe:= subi
);

code: BUTTON

FUNCTION_BLOCK BUTTON
VAR_INPUT
    IN: BOOL;
    PT: TIME;
END_VAR
VAR_OUTPUT
    pub: BOOL;
    payload:STRING;
END_VAR
VAR
    tx:TP;
    CNT: INT:=0;
    edge: BOOL:=FALSE;
    long: BOOL:=FALSE;
END_VAR
pub:= FALSE;

payload:='';
tx(IN:=IN,PT:=PT);
(* Q == true -> pressed *)
IF IN THEN
    IF NOT tx.Q THEN
        IF CNT = 0 THEN
            payload := 'long';
            pub:=TRUE;
            long:=TRUE;
            (* need to reinit the counter, still going strong! *)
            tx(IN:=FALSE,PT:=PT);
            tx(IN:=IN,PT:=PT);
        END_IF
    END_IF
ELSIF tx.Q AND edge THEN
    IF NOT long THEN
        (* found an edge!*)
        cnt := cnt +1;
    END_IF
    long:=FALSE;
END_IF
IF NOT tx.Q AND cnt > 0 THEN
    pub:=TRUE;
    payload := INT_TO_STRING(cnt);
    cnt := 0;
END_IF
edge := IN;

[BlackShadow]

jellevictoor schreef op maandag 5 juni 2017 @ 21:35:

Een belangrijke opmerking is dat het nodig is om effectief permissions te geven aan je outputs dat deze via modbus mogen geschreven worden.

Heb momenteel Modbus (wago 750-881 met 1405 en 1504).

Thx voor de permissions tip!

Als ik de PI Assignment verzet, kan de output niet meer gestuurd worden door een input op de PLC, enkel via MODBUS? Klopt dit?

jellevictoor schreef op zondag 11 juni 2017 @ 14:19:
Als mensen ook de PLC code willen, ik kan deze wel makkelijk op github gooien, ik wil er een functie van maken zodat ik dit makkelijk kan koppelen aan iedere input die een knop is, maar daarvoor moet ik me wat meer verdiepen in de plc code.

Hier alvast interesse in de PLC code.
Kan je ook MQTT berichten ontvangen op de PLC?

[ Voor 120% gewijzigd door BlackShadow op 19-08-2017 16:50 ]

[jellevictoor]

BlackShadow schreef op vrijdag 18 augustus 2017 @ 17:19:
[...]


Heb momenteel Modbus (wago 750-881 met 1405 en 1504).

Thx voor de permissions tip!
[afbeelding]
Als ik de PI Assignment verzet, kan de output niet meer gestuurd worden door een input op de PLC, enkel via MODBUS? Klopt dit?


[...]

Hier alvast interesse in de PLC code.
Kan je ook MQTT berichten ontvangen op de PLC?

een mqtt topic opzetten op een wago kan voor zover ik weet niet. In nieuwere modellen kan dit via het native OS die erop draait, denk ik

[BlackShadow]

jellevictoor schreef op zondag 20 augustus 2017 @ 19:48:
[...]


een mqtt topic opzetten op een wago kan voor zover ik weet niet. In nieuwere modellen kan dit via het native OS die erop draait, denk ik

Klopt het dat wanneer de PI Assignment voor outputs wordt verzet naar MODBUS, de output niet meer gewijzigd kan worden via code op de PLC zelf?

Ik wil mijn lichten gaan sturen en om niet afhankelijk te zijn van, in mijn geval, openhab om mijn lichten nog aan te kunnen zetten, dacht ik het aan- en uitschakelen in de PLC te programmeren. Alle automatisatie wordt geregeld in openhab, crasht deze, dan kan ik tenminste het licht nog aansteken.

Als blijkt dat een output niet via PLC code EN via modbus gestuurd kan worden, dan valt mijn hele plan in het water. Ook wordt de robuustheid en de betrouwbaarheid van de PLC teniet gedaan door er een software component tussen te zetten...

[MichVw]

BlackShadow schreef op zondag 20 augustus 2017 @ 21:57:
[...]


Klopt het dat wanneer de PI Assignment voor outputs wordt verzet naar MODBUS, de output niet meer gewijzigd kan worden via code op de PLC zelf?

Ik wil mijn lichten gaan sturen en om niet afhankelijk te zijn van, in mijn geval, openhab om mijn lichten nog aan te kunnen zetten, dacht ik het aan- en uitschakelen in de PLC te programmeren. Alle automatisatie wordt geregeld in openhab, crasht deze, dan kan ik tenminste het licht nog aansteken.

Als blijkt dat een output niet via PLC code EN via modbus gestuurd kan worden, dan valt mijn hele plan in het water. Ook wordt de robuustheid en de betrouwbaarheid van de PLC teniet gedaan door er een software component tussen te zetten...

Klopt, als je de handleiding doorneemt van de WAGO 750-881 word er duidelijk vermeld dat er maar één de outputs kan aansturen. Maar er zijn inderdaad andere manieren. rond pagina 81 van de wago manual vind je meer info omtrent de memory layout en wie welke permissies heeft op welk stuk geheugen (lezen/schrijven). Daaruit blijkt dat enkel het NOVRAM geheugen in range %MW0 tot %MW8192 zowel toegangelijk is voor de PLC en modbus om te lezen en te schrijven. Zelf maak ik van dit geheugen gebruik om flags te zetten voor een output hoog of laat te zetten. Hiermee is het dan inderdaad mogelijk om de robuustheid van de WAGO 750 te combineren met OpenHab2.

Om bovenstaande te prototypen kan ik Node-Red aanraden met de modbus library. Zo kan je heel vlot dingen gaan testen.

Het enige wat me nog rest is updates te pushen wanneer er een drukknop word ingedrukt of output word ingestuurd. Ik had gehoopt om dit via de HTTP_GET te kunnen doen van oscat maar die krijg ik maar niet aan de praat. Heeft er hier iemand meer ervaring meer? Ik ga me nu wat meer verdiepen in MQTT

[MichVw]

jellevictoor schreef op woensdag 21 juni 2017 @ 22:30:
ondertussen heb ik het niet meer voor gehad dat de PLC faalt bij het starten. Wanneer ik het opnieuw voor heb, ga ik dit proberen, thanks!

Ondertussen heb ik een generieke button geschreven die een mqtt genereerd en dat dan naar een topic stuurt op mijn PLC. Op die manier kan ik effectief pushen vanop mijn PLC.
Ik vroeg me af of er hier iemand enorm bedreven is in het schrijven van PLC software die mijn code even wil reviewen? Ik ben zelf programmeur, maar dit is compleet nieuw voor mij en vind geen zo'n grote online community. Ik ben hier dus wat aan het spelen met bestaande libs die ik mash tot een geheel.

Wat me enorm stoort aan deze code is dat het MQTT stuk aan het eind van de cycle moet. Wanneer ik dit niet doe, stuurt de PLC geen berichten en crashed de ganse IDE. Vandaar kan ik per cycle maar 1 bericht schrijven. In praktijk werkt het wel lekker, de cycles van de wago zijn zo snel, dat dit geen verschil maakt

code: PLC_PRG

PROGRAM PLC_PRG
VAR
    input_001 AT %IX0.0: BOOL;
    input_002 AT %IX0.1: BOOL;
    input_003 AT %IX0.2: BOOL;
    input_004 AT %IX0.3: BOOL;

    button_001: BUTTON;
    button_002: BUTTON;
    button_003: BUTTON;
    button_004: BUTTON;

    button_time: TIME:=t#600ms;

    pub:BOOL;
    subi:BOOL;
    payload:STRING;
    topic:STRING;
    mqttClient: MQTT_Client;
END_VAR

pub:=FALSE;
subi:=FALSE;
payload:='';
IF NOT pub THEN
    topic:='dev/switch/1';
    button_001(IN:=input_001, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/2';
    button_002(IN:=input_002, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/3';
    button_003(IN:=input_003, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/4';
    button_004(IN:=input_004, PT:=button_time, pub=>pub, payload=>payload);
END_IF

mqttClient(
    sTopic:= topic,
    sPayload:= payload ,
    sIp:= IP ,
    wPortNumber:= PORT ,
    sUsername:= USERNAME ,
    sPassword:= PASS,
    xPublish:= pub ,
    xSubscribe:= subi
);

code: BUTTON

FUNCTION_BLOCK BUTTON
VAR_INPUT
    IN: BOOL;
    PT: TIME;
END_VAR
VAR_OUTPUT
    pub: BOOL;
    payload:STRING;
END_VAR
VAR
    tx:TP;
    CNT: INT:=0;
    edge: BOOL:=FALSE;
    long: BOOL:=FALSE;
END_VAR
pub:= FALSE;

payload:='';
tx(IN:=IN,PT:=PT);
(* Q == true -> pressed *)
IF IN THEN
    IF NOT tx.Q THEN
        IF CNT = 0 THEN
            payload := 'long';
            pub:=TRUE;
            long:=TRUE;
            (* need to reinit the counter, still going strong! *)
            tx(IN:=FALSE,PT:=PT);
            tx(IN:=IN,PT:=PT);
        END_IF
    END_IF
ELSIF tx.Q AND edge THEN
    IF NOT long THEN
        (* found an edge!*)
        cnt := cnt +1;
    END_IF
    long:=FALSE;
END_IF
IF NOT tx.Q AND cnt > 0 THEN
    pub:=TRUE;
    payload := INT_TO_STRING(cnt);
    cnt := 0;
END_IF
edge := IN;

zoals vermeld in bovenstaande post ga ik me ook op MQTT toespitsen. heb je zelf nog vooruitgang geboekt de laatste weken? Om je code wat 'maintainable' te houden zou ik aanraden de

IF NOT pub THEN
topic:='dev/switch/4';
END_IF;

weg te werken in je functionblock.

[BlackShadow]

MichVw schreef op zondag 27 augustus 2017 @ 17:54:
[...]


Klopt, als je de handleiding doorneemt van de WAGO 750-881 word er duidelijk vermeld dat er maar één de outputs kan aansturen. Maar er zijn inderdaad andere manieren. rond pagina 81 van de wago manual vind je meer info omtrent de memory layout en wie welke permissies heeft op welk stuk geheugen (lezen/schrijven). Daaruit blijkt dat enkel het NOVRAM geheugen in range %MW0 tot %MW8192 zowel toegangelijk is voor de PLC en modbus om te lezen en te schrijven. Zelf maak ik van dit geheugen gebruik om flags te zetten voor een output hoog of laat te zetten. Hiermee is het dan inderdaad mogelijk om de robuustheid van de WAGO 750 te combineren met OpenHab2.

Om bovenstaande te prototypen kan ik Node-Red aanraden met de modbus library. Zo kan je heel vlot dingen gaan testen.

Het enige wat me nog rest is updates te pushen wanneer er een drukknop word ingedrukt of output word ingestuurd. Ik had gehoopt om dit via de HTTP_GET te kunnen doen van oscat maar die krijg ik maar niet aan de praat. Heeft er hier iemand meer ervaring meer? Ik ga me nu wat meer verdiepen in MQTT

Perfect, heb je wat plc en openhab code om te delen?

Dan ga ik ook kijken wat ik nog kan doen met MQTT, er is een library voor Wago 750 waarmee je kan subscriben, maar niet publishen.

[MichVw]

BlackShadow schreef op zondag 27 augustus 2017 @ 19:52:
[...]


Perfect, heb je wat plc en openhab code om te delen?

Dan ga ik ook kijken wat ik nog kan doen met MQTT, er is een library voor Wago 750 waarmee je kan subscriben, maar niet publishen.

plc code heb ik reeds, openhab code nog niet. ik focus me momenteel op kernfunctionaliteit in de PLC, kijken of alles correct werkt doe ik met behulp van Node-Red, eenmaal dat goed zit ga ik de openhab bindings configureren.

Ik heb dus wel alvast wat plc code voor je, het is wel een proof of concept er dient nog wat aan gesleuteld worden (function blocks maken etc..).

Om te beginnen maak ik gebruik van een sequential function chart om alles wat overzichtelijke te houden. Helaas kan ik er hier geen afbeelding van posten maar simpel gezegd voert het 2 stukjes codes uit achter elkaar in een loop; het lezen van de inputs en het schrijven van de outputs. voor de inputs maak ik gebruik van een drukknop in combinatie met de 'CLICK_MODE' function blok van OSCAT aangezien deze ook dubbelpushes en long presses kan detecteren.

Ik heb 2 variabelen in het NOVRAM geheugen om een ouput hoog of laag te maken, dit zijn dus simpele flags die kunnen geschreven worden aan de hand van modbus.

Variablen:

code:

PROGRAM PLC_PRG
VAR
    FB_DI_02_1: CLICK_MODE;
    DO_01_1_ON AT %MX0.0: BOOL;
    DO_01_1_OFF AT %MX0.1: BOOL;
END_VAR

Lezen inputs:

code:

FB_DI_02_1(
    IN:= DI_02_1,
    T_LONG:= T#400ms
);

Schrijven outputs:

code:

F (FB_DI_02_1.SINGLE OR DO_01_1_ON OR DO_01_1_OFF) THEN
    IF(DO_01_1 AND DO_01_1_OFF) THEN
        DO_01_1:=FALSE;
    END_IF
    IF(NOT(DO_01_1) AND DO_01_1_ON) THEN
        DO_01_1:=TRUE;
    END_IF
    IF(FB_DI_02_1.SINGLE) THEN
        DO_01_1:=NOT(DO_01_1);
    END_IF
    DO_01_1_ON:=FALSE;
    DO_01_1_OFF:=FALSE;
END_IF
IF FB_DI_02_1.DOUBLE = TRUE THEN
    DO_01_2:=NOT(DO_01_2);
END_IF
IF FB_DI_02_1.TP_LONG = TRUE THEN
    DO_01_3:=NOT(DO_01_3);
END_IF

Met deze code is het mogelijk om een single press/ double press en long press te detecteren op één enkele input. Daar komt nog bij dat de single press output kan gesimuleerd worden aan de hand van de flags in het NOVRAM geheugen. Werkt allemaal perfect, ik ga me nu wat bezighouden met er functieblokken en dergelijke van te maken. Hou er rekening mee dat data in het NOVRAM geheugen niet verloren gaat als de stroom uitvalt. het is dus belangrijk om parameters te resetten indien nodig tijdens startup van je PLC zodat er geen kans is dat er functioneel iets verkeerd gaat.

[jellevictoor]

MichVw schreef op zondag 27 augustus 2017 @ 17:58:
[...]


zoals vermeld in bovenstaande post ga ik me ook op MQTT toespitsen. heb je zelf nog vooruitgang geboekt de laatste weken? Om je code wat 'maintainable' te houden zou ik aanraden de

[...]


weg te werken in je functionblock.

Nee ben nu aan het verbouwen, weinig tijd hiervoor. ik zal opnieuw investeren eens de storm wat gaat liggen. Misschien kunnen we eens onze ervaringen delen in een groep video chat? Lijkt me wel leuk

[BlackShadow]

jellevictoor schreef op woensdag 21 juni 2017 @ 22:30:
ondertussen heb ik het niet meer voor gehad dat de PLC faalt bij het starten. Wanneer ik het opnieuw voor heb, ga ik dit proberen, thanks!

Ondertussen heb ik een generieke button geschreven die een mqtt genereerd en dat dan naar een topic stuurt op mijn PLC. Op die manier kan ik effectief pushen vanop mijn PLC.
Ik vroeg me af of er hier iemand enorm bedreven is in het schrijven van PLC software die mijn code even wil reviewen? Ik ben zelf programmeur, maar dit is compleet nieuw voor mij en vind geen zo'n grote online community. Ik ben hier dus wat aan het spelen met bestaande libs die ik mash tot een geheel.

Wat me enorm stoort aan deze code is dat het MQTT stuk aan het eind van de cycle moet. Wanneer ik dit niet doe, stuurt de PLC geen berichten en crashed de ganse IDE. Vandaar kan ik per cycle maar 1 bericht schrijven. In praktijk werkt het wel lekker, de cycles van de wago zijn zo snel, dat dit geen verschil maakt

code: PLC_PRG

PROGRAM PLC_PRG
VAR
    input_001 AT %IX0.0: BOOL;
    input_002 AT %IX0.1: BOOL;
    input_003 AT %IX0.2: BOOL;
    input_004 AT %IX0.3: BOOL;

    button_001: BUTTON;
    button_002: BUTTON;
    button_003: BUTTON;
    button_004: BUTTON;

    button_time: TIME:=t#600ms;

    pub:BOOL;
    subi:BOOL;
    payload:STRING;
    topic:STRING;
    mqttClient: MQTT_Client;
END_VAR

pub:=FALSE;
subi:=FALSE;
payload:='';
IF NOT pub THEN
    topic:='dev/switch/1';
    button_001(IN:=input_001, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/2';
    button_002(IN:=input_002, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/3';
    button_003(IN:=input_003, PT:=button_time, pub=>pub, payload=>payload);
END_IF
IF NOT pub THEN
    topic:='dev/switch/4';
    button_004(IN:=input_004, PT:=button_time, pub=>pub, payload=>payload);
END_IF

mqttClient(
    sTopic:= topic,
    sPayload:= payload ,
    sIp:= IP ,
    wPortNumber:= PORT ,
    sUsername:= USERNAME ,
    sPassword:= PASS,
    xPublish:= pub ,
    xSubscribe:= subi
);

code: BUTTON

FUNCTION_BLOCK BUTTON
VAR_INPUT
    IN: BOOL;
    PT: TIME;
END_VAR
VAR_OUTPUT
    pub: BOOL;
    payload:STRING;
END_VAR
VAR
    tx:TP;
    CNT: INT:=0;
    edge: BOOL:=FALSE;
    long: BOOL:=FALSE;
END_VAR
pub:= FALSE;

payload:='';
tx(IN:=IN,PT:=PT);
(* Q == true -> pressed *)
IF IN THEN
    IF NOT tx.Q THEN
        IF CNT = 0 THEN
            payload := 'long';
            pub:=TRUE;
            long:=TRUE;
            (* need to reinit the counter, still going strong! *)
            tx(IN:=FALSE,PT:=PT);
            tx(IN:=IN,PT:=PT);
        END_IF
    END_IF
ELSIF tx.Q AND edge THEN
    IF NOT long THEN
        (* found an edge!*)
        cnt := cnt +1;
    END_IF
    long:=FALSE;
END_IF
IF NOT tx.Q AND cnt > 0 THEN
    pub:=TRUE;
    payload := INT_TO_STRING(cnt);
    cnt := 0;
END_IF
edge := IN;

Heb wat geëxperimenteerd met bovenstaande code.
Echter lukt het me niet om daar een boot project van te maken, het programma loopt ergens vast na een herstart van de PLC.
Bij een run wordt de code wel netjes uitgevoerd.

Getest op een Wago 750-881.

Iemand hetzelfde probleem?

[MichVw]

BlackShadow schreef op zaterdag 9 september 2017 @ 19:04:
[...]


Heb wat geëxperimenteerd met bovenstaande code.
Echter lukt het me niet om daar een boot project van te maken, het programma loopt ergens vast na een herstart van de PLC.
Bij een run wordt de code wel netjes uitgevoerd.

Getest op een Wago 750-881.

Iemand hetzelfde probleem?

Ik heb ook problemen gehad met de MQTT library van FieldFox, zo is het bijvoorbeeld niet mogelijk om deze te gebruiken in combinatie met de OSCAT building library, de compilatie faalt dan. Ik heb geprobeerd om de MQTT library opnieuw te builden met de nieuwe versies van enkele librarys maar zonder succes.

Als je de branches bekijkt op de MQTT git repository van FielFox zal je zien dat SebastianRau de library verder ontwikkelt heeft. Zijn Git repo kan je hier vinden:

https://github.com/SebastianRau/Codesys2-Mqtt-lib

Laatste activiteit was daar ca. 2 weken geleden dus mocht je problemen hebben kan je daar een issue openen en krijg je hoogstwaarschijnlijk wel antwoord. Merk op dat de library van SebastianRau ander dependency libraries heeft dan die van FieldFox.

Ik deed er alvast enkele testen mee:

code:

PROGRAM PLC_PRG
VAR
    mqttClient: MQTT_Client;
        payload:STRING:='1';
        topic:STRING := 'test/Topic';
    Ip: STRING := '192.168.1.121';
    PortNumber: WORD := 1883;
    Clientid: STRING := 'WAGO 750-881';
    Username: STRING := '';
    Password: STRING := '';
    Publish: BOOL;
END_VAR

mqttClient(
        sTopic:= topic,
        sPayload:= payload ,
        sIp:= Ip ,
        iPortNumber:= PortNumber ,
    sClientid:= Clientid ,
        sUsername:= Username ,
        sPassword:= Password,
        xPublish:= Publish ,
);

IF DI_02_1 THEN
    Publish:= TRUE;
    payload:='hartbeat';
END_IF

Een paar bemerkingen:
-> getest op WAGO 750-881
-> getest: code compileert prima met de OSCAT building library (en deze is echt handig!)
-> getest: werkt ook als bootproject na opstart van PLC
-> getest: PLC programma blijft cyclus uitvoeren indien de MQTT broker niet bereikbaar is
-> build: deze MQTT library heeft de 'util.lib' library nodig om te builden. deze kan je vinden in de IO_IPC directory. Straight out of the box geeft die moeilijkheden op de WAGO 750-881 met de POU BLINK, je krijgt dan een fout in de aard van 'interface of POU blink unknown type TP'. Je kan deze POU echter uit je build halen door: Project -> options -> build -> Exclude objects -> navigeren naar util.lib -> selecteren POU BLINK -> aanvinken 'exclude from build' .

Succes! laat maar weten mocht je problemen hebben.

[BlackShadow]

MichVw schreef op maandag 11 september 2017 @ 11:41:
[...]


Ik heb ook problemen gehad met de MQTT library van FieldFox, zo is het bijvoorbeeld niet mogelijk om deze te gebruiken in combinatie met de OSCAT building library, de compilatie faalt dan. Ik heb geprobeerd om de MQTT library opnieuw te builden met de nieuwe versies van enkele librarys maar zonder succes.

Als je de branches bekijkt op de MQTT git repository van FielFox zal je zien dat SebastianRau de library verder ontwikkelt heeft. Zijn Git repo kan je hier vinden:

https://github.com/SebastianRau/Codesys2-Mqtt-lib

Laatste activiteit was daar ca. 2 weken geleden dus mocht je problemen hebben kan je daar een issue openen en krijg je hoogstwaarschijnlijk wel antwoord. Merk op dat de library van SebastianRau ander dependency libraries heeft dan die van FieldFox.

Ik deed er alvast enkele testen mee:

code:

PROGRAM PLC_PRG
VAR
    mqttClient: MQTT_Client;
        payload:STRING:='1';
        topic:STRING := 'test/Topic';
    Ip: STRING := '192.168.1.121';
    PortNumber: WORD := 1883;
    Clientid: STRING := 'WAGO 750-881';
    Username: STRING := '';
    Password: STRING := '';
    Publish: BOOL;
END_VAR

mqttClient(
        sTopic:= topic,
        sPayload:= payload ,
        sIp:= Ip ,
        iPortNumber:= PortNumber ,
    sClientid:= Clientid ,
        sUsername:= Username ,
        sPassword:= Password,
        xPublish:= Publish ,
);

IF DI_02_1 THEN
    Publish:= TRUE;
    payload:='hartbeat';
END_IF

Een paar bemerkingen:
-> getest op WAGO 750-881
-> getest: code compileert prima met de OSCAT building library (en deze is echt handig!)
-> getest: werkt ook als bootproject na opstart van PLC
-> getest: PLC programma blijft cyclus uitvoeren indien de MQTT broker niet bereikbaar is
-> build: deze MQTT library heeft de 'util.lib' library nodig om te builden. deze kan je vinden in de IO_IPC directory. Straight out of the box geeft die moeilijkheden op de WAGO 750-881 met de POU BLINK, je krijgt dan een fout in de aard van 'interface of POU blink unknown type TP'. Je kan deze POU echter uit je build halen door: Project -> options -> build -> Exclude objects -> navigeren naar util.lib -> selecteren POU BLINK -> aanvinken 'exclude from build' .

Succes! laat maar weten mocht je problemen hebben.

Bedankt, alles draait tot nu toe stabiel.
Ben ondertussen Home Assistant ook aan het bekijken naast openhab.

EDIT:
Zodra de connectie met de broker even wegvalt (bvb reboot van de machine), stuurt de Wago nadien geen MQTT meer in mijn huidige setup.
Zelfs als er geen ingangen hoog zijn geweest tijdens de downtijd.
Na een reboot van de PLC werkt alles terug zoals het hoort.

[ Voor 4% gewijzigd door BlackShadow op 14-09-2017 13:05 ]

[MichVw]

BlackShadow schreef op woensdag 13 september 2017 @ 17:58:
[...]


Bedankt, alles draait tot nu toe stabiel.
Ben ondertussen Home Assistant ook aan het bekijken naast openhab.

EDIT:
Zodra de connectie met de broker even wegvalt (bvb reboot van de machine), stuurt de Wago nadien geen MQTT meer in mijn huidige setup.
Zelfs als er geen ingangen hoog zijn geweest tijdens de downtijd.
Na een reboot van de PLC werkt alles terug zoals het hoort.

Ik heb zelfde gedrag kunnen nabootsen. Ga een issue openen op Github en zien wat er van komt.

[MichVw]

BlackShadow schreef op woensdag 13 september 2017 @ 17:58:
[...]


Bedankt, alles draait tot nu toe stabiel.
Ben ondertussen Home Assistant ook aan het bekijken naast openhab.

EDIT:
Zodra de connectie met de broker even wegvalt (bvb reboot van de machine), stuurt de Wago nadien geen MQTT meer in mijn huidige setup.
Zelfs als er geen ingangen hoog zijn geweest tijdens de downtijd.
Na een reboot van de PLC werkt alles terug zoals het hoort.

Fixed in dit github issue. en reeds getest. in een ander issue word er nog wat uitleg gegeven over hoe je best met de library omgaat om problemen te vermijden

[BlackShadow]

MichVw schreef op dinsdag 26 september 2017 @ 19:59:
[...]


Fixed in dit github issue. en reeds getest. in een ander issue word er nog wat uitleg gegeven over hoe je best met de library omgaat om problemen te vermijden

Bedankt om dit te delen, bug lijkt opgelost!

Ik heb ondertussen alles draaien in Home Assistant, de PLC stuurt input wijzigingen via MQTT naar Mosquitto, ik heb op deze manier geen last van gemiste inputs door de relatief trage Modbus polling time.

Via modbus stuur ik dan de uitgangen.

[BlackShadow]

Ik heb ondertussen een "Wago 750-352 ETHERNET Fieldbus Coupler" die ik probeer uit te lezen vanaf een Wago 750-881.

True/False van een bepaalde remote ingang via een variable lukt:




Met bij elkaar gesprokkelde informatie, ga er vanuit dat ik rechtstreeks de inputs van de Fieldbus Coupler kan uitlezen op de volgende manier:
input_021 AT %QW1.0: BOOL;

Om dan zoals de voorbeelden hierboven via MQTT over het netwerk te sturen.

Echter wil dit niet lukken, iemand hier ervaring mee?

EDIT

Alternatief is het volgende misschien:

frv schreef op vrijdag 2 september 2016 @ 11:58:

[...]


Die hoeveelheid koper kun je beperken.

Voor 2 kasten aan elkaar te hangen heb je bij wago 2 oplossingen :


2. een goedkope

de 750-628

Deze laat je toe over een ethernetkabel je bus te verlengen. (straight kabel dus niet via je bestaande netwerk en beperkt tot 5 meter (kan verhoogd worden via software tot 10 m)
Je verlengt dus in feite je bestaande kast alsof de modules in die kast zouden hangen op de controller waardoor je in de software de verschillende kasten als 1 geheel kunt programmeren.

Voordelen :

Prijs (80 euro op ebay)
De verschillende wago kasten worden in de software als 1 geheel aanzien.

Nadelen :

Niet integreerbaar in bestaand ethernet netwerk
Max 5M (uitbreidbaar tot 10 m)

Op die manier kan je per verdiep een kast bijzetten en kun je de hoeveelheid koper serieus beperken.

Kast 1 Garage -> 220V + Ethernet + 24V voeding -> Kast 2 (+ extra kasten)

Je hebt dan 3 kabels tussen de kasten (een zware 220 afhankelijk van de belasting op de kast, een 24V voeding en ethernet buskabel

Kostprijs is dus 80 euro/kast (hoewel ik denk dat je die modules nog goedkoper kan vinden mits wat creatief shoppen op ebay) + 10 m ethernet kabel + 10 meter 24v kabel + 10 M 220 V kabel (Nu is het 15 meter zal het ook wel werken. Heb zo een vermoeden dat die beperking eerder is om ook hun duurdere ethernet/modbus modules niet uit de markt te duwen)

Rekening houdend met kap/boorwerk bij renovatie, tijd om leidingen te leggen, prijs koper, installatiegemak lijkt me 80 euro / kast een schijntje.

Klopt het dat je ook de 750-627 nodig hebt als eindklem om dan met een UTP kabel naar een 750-628 te gaan?
Voorbeeld voor 3 kasten:

code:

          KAST 1                          KAST 2                            KAST 3
[750-881 + ... + 750-627]---UTP---[750-628 + ... + 750-627]---UTP---[750-628 + ... + 750-600]

Dit kan een oplossing zijn voor mijn geval, al denk ik dat de afstand iets langer dan 10 meter is....

[ Voor 66% gewijzigd door BlackShadow op 17-11-2017 15:15 ]

[frv]

@BlackShadow zelfs met meerdere controllers in modbus heb je maar 1 master. Dus in principe kan je via homeassistant de master uitlezen. Echter als je modbus gebruikt dan heb je aan de extra controllers weinig (een controller als modbus slave kan enkel aangestuurd worden door de master en niet zelf uitgangen schakelen) Foefjes zoals NOVRAM gebruiken daarvoor zou ik toch voor passen (Dat geheugen is daar niet voor bedoeld)

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

Zie p14 en 15

Wat wil je precies met home assistant gaan aansturen ? Afhankelijk daarvan zijn er andere oplossingen ... (mqtt bv ... elke individuele controller kan dan events via mqtt gaan sturen. Ben je meteen je single point of failure kwijt)

[ Voor 45% gewijzigd door frv op 29-11-2017 13:45 ]

[BlackShadow]

frv schreef op woensdag 29 november 2017 @ 13:32:
@BlackShadow zelfs met meerdere controllers in modbus heb je maar 1 master. Dus in principe kan je via homeassistant de master uitlezen. Echter als je modbus gebruikt dan heb je aan de extra controllers weinig (een controller als modbus slave kan enkel aangestuurd worden door de master en niet zelf uitgangen schakelen) Foefjes zoals NOVRAM gebruiken daarvoor zou ik toch voor passen (Dat geheugen is daar niet voor bedoeld)

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

Zie p14 en 15

Wat wil je precies met home assistant gaan aansturen ? Afhankelijk daarvan zijn er andere oplossingen ... (mqtt bv ... elke individuele controller kan dan events via mqtt gaan sturen. Ben je meteen je single point of failure kwijt)

De huidige situatie:
Mijn 750-881 stuurt momenteel MQTT die ik verwerk in Home Assistant, de uitgangen op de PLC stuur ik aan vanuit Home Assistant via MODBUS.

Ik heb momenteel enkele Modbus Python scripts uit Home Assistant aangepast zodat ik een modbus2 object kan aanmaken, dit verloopt momenteel vrij goed.

De PLC is momenteel in gebruik voor verlichting, slimme deurbel en bewegingssensoren.
Allen werkende via MQTT.

[ Voor 10% gewijzigd door BlackShadow op 29-11-2017 14:24 ]

[frv]

@BlackShadow Waarom stop je daar modbus in ? Kan je niet gewoon home assistant laten mqtt sturen en de wago hierop laten reageren ? Het voordeel hieraan is dat je dan in de 881 nog enige logica kan stoppen (zeker als je er meerdere hebt). Als home assistant crashed dan blijft de basis tenminste nog werken (er vanuitgaande dat je fysieke schakelaars aan de wago hangt en niet aan home assistant). Mogelijk ten onrechte maar ik ben altijd wat wantrouwend geweest tov van zaken als home assistant en domoticz. ZOlang het werkt is dat goed maar bij een update of crash kan er wel es iets uitvallen. De wago daarentegen : Als je prog eenmaal werkt dan blijft het werken ...

[ Voor 25% gewijzigd door frv op 30-11-2017 11:19 ]

[BlackShadow]

frv schreef op donderdag 30 november 2017 @ 11:18:
@BlackShadow Waarom stop je daar modbus in ? Kan je niet gewoon home assistant laten mqtt sturen en de wago hierop laten reageren ? Het voordeel hieraan is dat je dan in de 881 nog enige logica kan stoppen (zeker als je er meerdere hebt). Als home assistant crashed dan blijft de basis tenminste nog werken (er vanuitgaande dat je fysieke schakelaars aan de wago hangt en niet aan home assistant). Mogelijk ten onrechte maar ik ben altijd wat wantrouwend geweest tov van zaken als home assistant en domoticz. ZOlang het werkt is dat goed maar bij een update of crash kan er wel es iets uitvallen. De wago daarentegen : Als je prog eenmaal werkt dan blijft het werken ...

Ik heb ook mijn twijfels over de stabiliteit van Home Assistant en co (al draait alles nu toch al weken stabiel), maar ik ben nog geen library tegen gekomen die de 750-881 in staat stelt om MQTT topics te subscriben, enkel publishen.

[MichVw]

Persoonlijk merk ik wel dat eenmaal je een beetje goed overweg kan met ST in de wago home assistant naar mijn aanvoelen overbodig is

niet helemaal akkoord hier, de mogelijkheden met HA en OpenHAB zijn veel groter naar integratie toe met andere system. Ideaal zou zijn om basisfunctionaliteit te programmeren in de PLC en dan aan de hand van communicatie tussen PLC en bv OpenHAB outputs te gaan schakelen en events op inputs door te sturen. voor uitgaande communicatie vanuit de PLC kan je inderdaad MQTT gebruiken (SebastianRau lib is zeer goed hiervoor). voor communicatie naar de PLC toe is het inderdaad wat moeilijker, zeker als je wat geavanceerdere zaken wilt gaan doen is Modbus niet meer voldoende.

Momenteel probeer ik een TCP server te implementeren in ST op de PLC om dan vanuituit OpenHAB TCP berichten te gaan sturen. Maar het zal nog even duren voor dit 100% goed is opgezet.

[Femme]

frv schreef op dinsdag 5 december 2017 @ 09:51:

Persoonlijk merk ik wel dat eenmaal je een beetje goed overweg kan met ST in de wago home assistant naar mijn aanvoelen overbodig is.

Dat kan als je alles via de Wago kunt aansturen en geen behoefte hebt aan mooie visualisatie of app om je systeem te bedienen. Als je ook draadloos nodig hebt in je huis zijn je opties met een Wago vziw beperkt tot EnOcean en wellicht KNX-RF. Z-wave is geen optie terwijl dat wel veruit de populairste en betaalbaarste oplossing is (433MHz hobbyspul even buiten beschouwing latend).

frv schreef op donderdag 30 november 2017 @ 11:18:
@BlackShadow Waarom stop je daar modbus in ? Kan je niet gewoon home assistant laten mqtt sturen en de wago hierop laten reageren ? Het voordeel hieraan is dat je dan in de 881 nog enige logica kan stoppen (zeker als je er meerdere hebt). Als home assistant crashed dan blijft de basis tenminste nog werken (er vanuitgaande dat je fysieke schakelaars aan de wago hangt en niet aan home assistant). Mogelijk ten onrechte maar ik ben altijd wat wantrouwend geweest tov van zaken als home assistant en domoticz. ZOlang het werkt is dat goed maar bij een update of crash kan er wel es iets uitvallen. De wago daarentegen : Als je prog eenmaal werkt dan blijft het werken ...

Ik heb zelf de keuze gemaakt om alle logica te programmeren in PHP-scripts en PHP-modules voor IP-Symcon, zodat de logica los staat van de hardwareimplementatie.

De basis in de Wago stoppen is voor mij geen optie omdat het te complex is. Je moet dan alles dubbel uitvoeren in de Wago: de configuratie van de ruimtes met de bijbehorende pulsdrukkers en lichtpunten, scenes en dim-levels/kleuren die daar bij horen.

Ik heb geen ervaring met Domoticz en OpenHab maar IP-Symcon best wel stabiel. Je moet er wel meer aan managen zoals leteen op de beschikbare vrije opslagruimte en je code zo bouwen dat processen zich niet opstapelen als bijvoorbeeld een z-wave actor eens een keer niet reageert maar het proces ondertussen wel gestart blijft worden omdat er beweging wordt gedetecteerd, maar dat zin dingen waar je in elke programmeerbaar systeem last van kunt krijgen.

[frv]

MichVw schreef op dinsdag 12 december 2017 @ 20:46:
[...]


niet helemaal akkoord hier, de mogelijkheden met HA en OpenHAB zijn veel groter naar integratie toe met andere system. Ideaal zou zijn om basisfunctionaliteit te programmeren in de PLC en dan aan de hand van communicatie tussen PLC en bv OpenHAB outputs te gaan schakelen en events op inputs door te sturen. voor uitgaande communicatie vanuit de PLC kan je inderdaad MQTT gebruiken

Elk heeft andere noden. Voor mijn noden volstaat wat ik in de pLC kan stoppen (visualisaties en zo zijn mooi maar persoonlijk bekijk ik die zelden na enkele weken...

MichVw schreef op dinsdag 12 december 2017 @ 20:46:
[SebastianRau lib is zeer goed hiervoor). voor communicatie naar de PLC toe is het inderdaad wat moeilijker, zeker als je wat geavanceerdere zaken wilt gaan doen is Modbus niet meer voldoende.

Momenteel probeer ik een TCP server te implementeren in ST op de PLC om dan vanuituit OpenHAB TCP berichten te gaan sturen. Maar het zal nog even duren voor dit 100% goed is opgezet.

Is het niet simpeler om via netwerkvariabelen te werken dan ? Als ik me het goed herinner is dat simpel UDP broadcast ...

[Alex38]

Heeft iemand hier ervaring met deze Codesys MQTT library?

http://codesys-mqtt-library.sourceforge.net/

[Sandolution]

Hi allemaal,

Zelf ben ik ook aan het kijken om mijn domotica systeem uit te breiden met een PLC

Ik ben ooit begonnen met OpenHAB op een Pi1, maar na de release van OpenHAB 2 kan ik mijn RFlink niet meer aansluiten. Daarnaast was Java niet mijn sterkste kant. Ik ben daarom destijds overgestapt op Domoticz. Deze ondersteunde niet alleen RFlink, maar ook MySensors en nog wat andere bruikbare dingen.

Omdat ik nog bij mijn ouders woon, heb ik niet de mogelijkheid om deze woning te verbouwen. Daarom heb ik de lampen in het huis voorzien van aangepaste KlikAanKlikUit schakelaars,waarbij de originele printplaat vervangen is door mijn eigen printplaat die via NRF24L01 communiceert met de MySensor Gateway op de PI. Ook hebben deze schakelaars nu wat meer sensoren zoals beweging, lichtintensiteit en temperatuur. Daarover misschien later meer.

Ik heb afgelopen maand een complete re-design van het 'hart' van het systeem gedaan: Alles netjes in een kastje (Schneider Thalassa), op DIN-rail. Dat ziet er als volgt uit:

Daarin is links onderin een Wiemann 24V2,5A voeding te zien. Bovenin zijn omvormers naar 3.3v en 5v, de PI 3B+, custom printplaat voor aansluitingen, Arduino Mega (RFLink) en de NRF24L01-PA te zien. Verder nog een rijtje Wago klemmen om de voedingen te verdelen. Ik moet er nog wartels in maken voor de kabels naar buiten toe.

Het idee van dit systeem is om een klein, compact systeem te maken wat in de meterkast gehangen kan worden. Er hoeft ook alleen maar basic functionaliteit in zoals licht, weer etc. Als ik na de zomer mijn eigen huis heb, wil ik een veel uitgebreider systeem gaan maken. Hoe dat precies vorm moet gaan krijgen weet ik nog niet.

Echter, om daar alvast op voor te bereiden, ben ik bezig met het koppelen van een CoDeSys3 PLC aan Domoticz. Gezien PLC programmeren mijn werk is, ben ik op dat vlak veel sterker dan bijvoorbeeld programmeren van LUA of DzVents. Daarbij maak ik gebruik van Domoticz/Raspbian als koppeling met de verschillende sensoren en functies die niet in een PLC kunnen. Veel zaken worden middels CRON-jobs geschreven naar custom sensoren van Domoticz.

Die lees ik uit via HTTP-requests vanuit de PLC. Zo heb ik alle data van Domoticz ook in mijn PLC, waarmee ik dus makkelijk kan programmeren. Aansturen gebeurd op dezelfde manier. Ik wil tevens nog kijken of dit eventueel via MQTT kan. Alles is nog in een begin stadium, dus nog volop in ontwikkeling.

Ik gebruik daarvoor een C300 PLC van Lenze:


Die kost ongeveer rond de €300 euro. Daarbij komt dan nog wel de programmeer software. Ik weet zo even niet wat die kost, gezien ik die van het werk heb. Wel weet ik dat die 30 dagen gratis uit te proberen is:
http://www.lenze.com/en-gb/go/akb/201105919/1/.

Achter deze PLC kunnen eventueel ook I/O slices gehangen worden voor interfacing met de wereld. Hiervoor zijn verschillende type modules beschikbaar, net als het Wago systeem.

In de toekomst wil ik de losse PLC misschien vervangen door een scherm met ingebouwde PLC: De P300. Daarbij zit dus de CoDeSys3 PLC en de visualisatie in één. Daar kunnen dan echter geen losse I/O slices aan verbonden worden, maar die kunnen weer verbonden worden middels een EtherCAT kopstation.
.

Al met al dus ideeën zat om de domotica te laten besturen vanuit een PLC!

[ Voor 4% gewijzigd door Sandolution op 05-01-2019 17:48 ]

[matthijs33]

Het is ondertussen al enkele maanden geleden dat ik in dit forum mijn plannen heb gedeeld voor in mijn nieuwbouw woning.

Ondertussen ben ik 2 weken geleden verhuisd, en doet de WAGO PLC zijn (basic) werk.
Momenteel worden alle lichten, rolluiken, screens en de 2 dimmers (6 kanalen) bestuurd door de PLC.

De lichten worden met drukknoppen binnen gelezen in digitale ingangen, en met digitale uitgangen worden relais aangestuurd (16A).
De screens en rolluiken gebruiken ook digitale in-en uitgangskaarten en hebben 2 relais per screen/rolluik (20 relais in totaal).
De PLC heeft ook een DMX module om de 2 dimmers aan te sturen.
Dit alles is in een industriële metalen kast geplaatst (0.8x1m)


De volgende stap is een UI te voorzien op een Rasberry PI, om alles via de GSM te kunnen besturen.
Over de software voor de UI ben ik nog niet helemaal over uit, de communicatie tussen de PI en de WAGO PLC zal waarschijnlijk MQTT worden.
De bedoeling is dat deze software de geavanceerdere taken op zich neemt, maar de basis taken zullen blijven werken met enkel de PLC. (als de PI crashed, dat ik alles nog kan bedienen met de drukknoppen in huis.)
Hopelijk heb ik hier de komende maanden wat tijd voor, maar er is ook nog ander werk in het huis die de nodige prioriteit nodig heeft

Vragen of (opbouwende) kritiek is altijd welkom

[MichVw]

[b]
De lichten worden met drukknoppen binnen gelezen in digitale ingangen, en met digitale uitgangen worden relais aangestuurd (16A).
De screens en rolluiken gebruiken ook digi

De volgende stap is een UI te voorzien op een Rasberry PI, om alles via de GSM te kunnen besturen.
Over de software voor de UI ben ik nog niet helemaal over uit, de communicatie tussen de PI en de WAGO PLC zal waarschijnlijk MQTT worden.
De bedoeling is dat deze software de geavanceerdere taken op zich neemt, maar de basis taken zullen blijven werken met enkel de PLC. (als de PI crashed, dat ik alles nog kan bedienen met de drukknoppen in huis.)
Hopelijk heb ik hier de komende maanden wat tijd voor, maar er is ook nog ander werk in het huis die de nodige prioriteit nodig heeft

Vragen of (opbouwende) kritiek is altijd welkom

Momenteel heb ik ook de basislogica in m'n plc zitten, communicatie gebeurd via verschillende protocols:

• modbus voor het uitlezen van de outputs
• mqtt voor het uitsturen van events op inputs (single press, double press of long press)
• tcp voor het sturen van commando's naar de plc

Alles gaat via openhab, openhab heeft een flinke leercurve maar het is het zeker waard. Alleen al naar andere integraties toe is er heel veel mogelijk. Als je dan voor frontend iets (custom) anders wilt doen kan je gebruik maken van de mogelijkheid om de Openhab eventbus te expanden via mqtt (krijg je updates per events en kan je commandos sturen ook via mqtt).

Mijn verdere tips:

• leer/gebruik docker(-compose), je kan je volledige setup starten met één docker commando, ook naar disaster recovery heel interessant (alle hardware faalt vroeger of later)
• als je voor docker kiest: zoek hardware met een intel/amd cpu. Het overgrote deel van de bestaande docker containers is hiervoor gemaakt. Voor ARM is de ondersteuning beperkt, als je tenslotte kijkt naar het openhab forum word de rpi zelf afgeraden (sd kaartjes falen constant wegens teveel io)

Zelf heb ik alles in docker containers (mqtt broker + openhab) en kan ik alles online brengen aan de hand van één enkele docker-compose file. Al de configuratie van de mqtt broker en openhab is via files dus die zitten gewoon samen met m'n docker compose in een git repo

Om alles te starten op een nieuwe host dien ik gewoon docker te installeren, m'n git repo pullen en 'docker-compose up' geven als commando en alles is live.. naar mijn mening een enorme meerwaarde maar iedereen z'n eigen zin natuurlijk succes!

[Antonius]

meddle schreef op zondag 20 mei 2018 @ 16:03:
Verder zit ik met de vraag wat ik het beste voor software kan doen. De bedoeling is dat het systeem uiteindelijk bestuurd wordt door de controller en met een HMI via een simpele interface in te stellen is, en dus kunnen draaien zonder externe software op een PC/server. Ik had begrepen dat ik de PLC via codesys v3 for PFC200 kan programmeren en dat ik (daarmee?) ook een HTML5 web interface kan maken waar mensen oa. temperatuur en instelling kunnen zien. Ik zag echter ook dat Wago zelf software verkoopt voor zijn PLC's zoals wago I/O check, wago e!cockpit en nog wat andere programma's die vrij duur zijn. Heb ik die pakketten dan ook nodig naast codesys voor de PFC200 om de volledige functionaliteit van de PLC te kunnen benutten? Dit laatste is me niet helemaal duidelijk.

Om alleen temperatuur te meten is dit overkill en prijzig, maar wel een prima basis om uit te bouwen naar de andere zaken.

Voeding: ik weet niet wat de Wago voeding kost, kan ook een andere 24V voeding zijn. Ik zou wel DIN rail mount nemen. Ik heb goede ervaringen met Meanwell voedingen in combinatie met PLC's.

Software: kan zowel met E!Cockpit (duur) als met de PFC200 codesys control en standaard Codesys v3. Bij de Wago software kun je gebruik maken van Wago support, met de runtime van 3S Software ben je wat dat betreft iets meer op jezelf aangewezen. Lees voordat je kiest even na of de Wago modules die je nu en in de toekomst wilt gaan gebruiken allemaal ondersteund worden door de runtime van 3S.

Voor gebruik met 1 PLC is de 3S oplossing prima. Als je meerdere PLC's gaat programmeren, dan wordt de E!Cockpit software op een gegeven moment goedkoper want geen meerprijs per PLC. Ik doe er (beroepsmatig) een flink aantal per jaar, dan kan het wel uit


Wat wil je met de temperatuur en evt andere gegevens gaan doen? Alleen instant zichtbaar maken, of ook historie vastleggen? In dat laatste geval kun je alvast denken over hoe je dat wilt doen. Bijvoorbeeld:

• loggen naar tekst/CSV bestand op SD en soms er even uithalen of via FTP uitlezen
• interface voorzien zodat een ander systeem continu of periodiek kan uitlezen tbv loggen, bijv modbus over ethernet of RS485
• loggen via ethernet naar externe opslag (bijv naar SQL server, MySQL, ...)
• loggen via seriele aansluiting naar externe opslag (bijv naar SQL server, MySQL, ...)
• MQTT

Dat kan zelfs al naar iets simpels als een Raspberry PI waar je gegevens in een database vastlegt en op een dashboard visualeert, direct via HDMI op tv scherm of ook weer via een web interface.

IMHO is het zonde om de data wel te meten maar geen historie vast te leggen. Dat kan erg nuttig zijn om beslissingen op te baseren (kan bijvoorbeeld ook gedaan worden met stroomverbruik icm zonnepanelen en investeringsbeslissingen om daar beter mee om te gaan).

[mhemeryck]

Ik was ondertussen redelijk overtuigd van de unipi neuron reeks (https://www.unipi.technology/unipi-neuron-l303-p101 -- heb er ondertussen zelfs zo eentje aangeschaft) maar het probleem dat ik hier zie is dat je niet zo makkelijk IO kunt bijzetten als je bvb bij de Wago PLCs wel kunt.

Vooraleer ik het hele concept nog eens zou omgooien, had ik aantal praktische vragen bij de wago PLC, e.g. de PFC200:
* plaatsing in kast: past dit in een "klassieke" verdeelkast? Ik had gedacht aan 1 grote kast voor zowel de zekeringen (220V) als de PLC. Voor de unipi Neuron zou dat geen probleem zijn. Ik ben qua kasten aan het kijken naar verdeelkasten zoals van Vynckier, Schneider Electric, Legrand ...
* programmatie: ik zie codesys hier vaak terugkomen, maar dat is allemaal windows-based / grafische ontwikkelomgeving, wat voor mij een no-go is. Ik vroeg me af wat soort van distro er draait op die PFC200 (linux met RT-patch -- ik schat hun eigen linux build) en hoe makkelijk het is om rechtstreeks op de PLC te programmeren. In een ideale wereld heeft wago ergens een library om events op de bus op te vangen en deze bijvoorbeeld via MQTT af te vuren -- maar ik weet niet hoe realistisch zoiets is.
* DALI: is blijkbaar een van de klemmen die wago ook aanbiedt; iemand ervaring mee?

[Femme]

Oystein schreef op vrijdag 20 juli 2018 @ 16:51:
Voor een PLC sturing (ben met de Siemens Logo e.e.a. aan het uitwerken) heb ik alleen mechanische drukknoppen nodig voor licht en zonnescherm schakelaars e.d.

Terwijl er in KNX zoveel mooie tasters (4-6 voudig) beschikbaar zijn blijkt het erg beperkt in NO drukschakelaars.
Ik kom eigenlijk alleen Niko tegen.

Hebben jullie nog een paar mooie voorbeelden of alternatieven?

In ons gastenverblijf gebruik ik enkel- en tweevoudige pulsdrukkers van Niko met afwerking in Niko Pure aluminium. Duur, maar ook erg mooie afwerking en een super degelijk mechanisch schakelgevoel in de knoppen. De vier- en zesvoudige pulsdrukkers van Niko hebben niet dat degelijke mechanische schakelgevoel.

In de rest van het huis heb ik enkel- en tweevoudige pulsdrukkers van Merten met afwerking in Merten Artec. Wat minder strak maar wel een stuk betaalbaarder (zie bijv. Voltus.de voor prijzen). In deze serie zijn er echter geen vier- of zesvoudige drukknoppen in één afdekraampje.

mhemeryck schreef op zondag 22 juli 2018 @ 11:42:
Ik was ondertussen redelijk overtuigd van de unipi neuron reeks (https://www.unipi.technology/unipi-neuron-l303-p101 -- heb er ondertussen zelfs zo eentje aangeschaft) maar het probleem dat ik hier zie is dat je niet zo makkelijk IO kunt bijzetten als je bvb bij de Wago PLCs wel kunt.

Vooraleer ik het hele concept nog eens zou omgooien, had ik aantal praktische vragen bij de wago PLC, e.g. de PFC200:
* plaatsing in kast: past dit in een "klassieke" verdeelkast? Ik had gedacht aan 1 grote kast voor zowel de zekeringen (220V) als de PLC. Voor de unipi Neuron zou dat geen probleem zijn. Ik ben qua kasten aan het kijken naar verdeelkasten zoals van Vynckier, Schneider Electric, Legrand ...
* programmatie: ik zie codesys hier vaak terugkomen, maar dat is allemaal windows-based / grafische ontwikkelomgeving, wat voor mij een no-go is. Ik vroeg me af wat soort van distro er draait op die PFC200 (linux met RT-patch -- ik schat hun eigen linux build) en hoe makkelijk het is om rechtstreeks op de PLC te programmeren. In een ideale wereld heeft wago ergens een library om events op de bus op te vangen en deze bijvoorbeeld via MQTT af te vuren -- maar ik weet niet hoe realistisch zoiets is.
* DALI: is blijkbaar een van de klemmen die wago ook aanbiedt; iemand ervaring mee?

Wat betreft I/O is het systeem van Wago fantastisch. Het neemt het weinig ruimte in en je kunt per module van 12mm breed twee tot zestien I/O kanalen bijschakelen. Je neemt alleen wat nodig is en je kunt zo'n beetje elk denkbare signalerings- en communicatietechniek in je systeem integreren. Ik heb zelf veel gebruikte modules van eBay.de gebruikt. Nooit problemen mee en de kosten vallen dan ook erg mee, zeker voor digitale inputs en outputs.

Een FPC200 kan gewoon in een standaard verdeelkast ingebouwd worden. Programmeren heb ik zelf eigenlijk minimale ervaring mee. Vooralsnog gebruik ik modbus om met de PLC te communiceren. Er zijn MQTT libraries voor CoDeSys om efficiënter te communiceren.

[Patrick_v_L]

Hallo allemaal,

Om te beginnen; Wow! Wat een topic en wat een bak aan voorbeelden, kennis en ervaring is hier samengebracht op Tweakers! Zelf ben ik veel bezig met IoT via Node-Red en de Chinese 5v modules op Arduino en ESP's. Maar dit forum heeft mij naar een ander level gebracht in mijn onderzoek voor mijn nieuwbouwhuis welke eind Q4 2019 opgeleverd gaat worden! (Standaard rijwoning)

Om te beginnen is de intentie nog niet om zo uitgebreid te gaan als Femme, maar ik ken mijzelf, ik begin met een klein plan en uiteindelijk hangt er RGBW via DMX in elk waterornament in de tuin ;-) Ik zal beginnen mijn plan/idee te posten met een paar 'aannames' waar ik op vastloop. Hopelijk heeft er iemand een moment om mij de juiste richting in te duwen!

Het plan om in het nieuwe huis te gaan doen
• Alle lichtpunten via een relay op de PLC d.m.v. een DO-kaart
• Alle schakelaars vervangen door druk-schakelaars via de PLC d.m.v. een DI-kaart
o 2/3 buttons per schakelaar, dat dimmende effect is wel super mooi!
o WC => Bewegingssensor
• TV-meubel zaken komen de relays achter het meubel te hangen, geschakeld vanaf de PLC d.m.v. een DO-kaart
• Electrische kachels schakelen via een relay op de PLC d.m.v. een DO-kaart
• 1-Wire om in elke kamer de temp te meten via "achter het klepje verscholen DS18B20 soldeertruckje"
• RGBW + DMX voor wat kleine sfeerverlichting aan de muur in de woonkamer later ook evt. tuinverlichting/keuken/trap

Wat ik nog wil uitzoeken;
• Wat voor vitrage/gordijnen ik ga nemen en met welke aansturing
• Hoe ik de warmtepomp van de vloerverwarming kan regelen (Moet ik eerst weten welke apparatuur er komt te hangen!)
• Water/Electra verbruik + Zonnepanelen kan uitlezen (Moet ik eerst weten welke apparatuur er komt te hangen!)
• Voorbereiding voor screen's/zonnescherm
• Of ik nog iets wil in de badkamer qua (DMX)licht en/of schakelingen
• Wat ik wil met Pir/Radar sensors
• Domotica pakket, voorkeur gaat nog wel naar IP-Symcon, ben van origine een PHP'ert
• En alles waar ik nog tegen aan ga lopen ;-)
Er komt meer detail op het moment dat ik alle technische tekeningen van het huis in bezit heb!

Dit alles wil ik laten aansturen door een WAGO PFC200 (750-8202) op een 24V din voeding.
Zelf heb ik voor deze gekozen na een klein onderzoekje rondom alle PLC's en WAGO modules.
• RS-232/-485 (switchable), handig voor DMX (aanname dat dit werkt!)
• Ondersteunt alle 750/753 WAGO modules
• HTML5 interface (eventueel voor de nood schakelingen), ben allergisch voor JAVA!

Mijn (test)setup zal worden;
• WAGO PFC200 (750-82020)
• 24V voeding
• DO-4 (750-504)
• DI-4 (750-402)
• Endmodule (750-600)
• 4 Relay's, ik denk de Finder Relay's
• 4 Lampen o.i.d. zodat het resultaat / de schakeling zichtbaar is
• Aangestuurd door RPI3 met IP-Symcon in de testmodus
• en natuurlijk netjes op rail klemmen afgemonteerd!

Paar aannames/vragen waar ik op blijf steken;

• De DO/DI-kaarten zijn er in 2/4/8/16 poort varianten. Nemen jullie de 4p variant omdat deze voor nog geen 10 euro stuk op ebay.de staan, of is het omdat de 16p variant kei onoverzichtelijk is qua bekabeling?

• Qua DI-kaarten kan je kiezen tussen een 3ms en een 0,2ms variant. Zien jullie problemen in het schakelen van de 3ms variant tov de 0,2ms?

• Qua de drukknoppen zweeft er ergens een scriptje rond om de waardes iets langer actief te houden zodat de polling vanuit bijv IPSym deze kan opvangen. Om het systeem te laten werken heb ik dus alleen een licentie van CodeSys PFC200 nodig om dit soort zaken in de PLC te programmeren? De WAGO software heb ik dus helemaal niet nodig?! (btw, ik heb nog te weinig onderzoek gedaan naar de MQTT module voor de PLC, dus ik blijf nog even op het poll systeem qua denken!)

• Iemand ervaring met de DMX op de ingebakken WAGO RS485 poort? Of uberhaubt via de WAGO? Deze vraag aangezien Femme dit via een los apparaat doet.

• Ik zie dat de WAGO niet direct beschreven kan worden om de status van een uitgang aan te sturen. Klopt mijn gedachten dat jullie hiervoor een registerveld gebruiken welke de PLC uitleest? IP-Symcon schrijft dan naar dit registerveld en de PLC pakt dit op? Moet dit toch zeker ook in de PLC geprogrammeerd worden via CodeSys?!

Dank alvast!

Groet Patrick

[illektro]

Hallo allen. Long time reader, first time poster.

Ik zit nog echt in de pre-game excitement phase van home automation. Ik ben vooral een dromer en nog niet echt een doener; ik ben eigenaar van een huis waaraan ik niet veel meer wil doen. Ik heb grote ambities om te emigreren, en daar te zijner tijd een huis te bouwen. Het is een droom, maar wel een die ik graag wil waarmaken en waar ik me hard voor wil inzetten.

Een huis van de toekomst, ubiquitous, smart-home, of welke term je het ook wilt geven; dit is iets waar ik echt in geïnteresseerd ben. Ik vind het ongelooflijk gaaf hoe snel de technologie tegenwoordig beweegt.

Ik ben software engineer in hart en nieren. Ik weet eigenlijk veel te weinig van hardware en elektra, maar ik hoop een heleboel goed te maken duur pure interesse en wat goodwill van vrienden die wel van wanten weten. Ik ben niet vies van PHP, maar ik zou alles veel liever in JavaScript programmeren. Ik ben fan van Node, en het hele async / event-driven paradigm. Het liefst zou ik alle domotica laten draaien op MQTT of Websockets communicatie, omdat ik daar al veel ervaring mee heb. In dit topic (een schat aan informatie!) ben ik al een aantal keren mogelijkheden hiervoor tegengekomen, maar dit onderwerp is zo enorm groot, ik heb nog een heleboel te leren over alle mogelijkheden.

Mijn droomhuis staat hopelijk binnen een paar jaar ergens in het zonnige Australië, is energie neutraal, en moet het volgende aansturen:

• Aanwezigheidsdetectie (accuraat Indoor Positioning System zou tof zijn)
• HVAC
• Lichten
• Multi-room audio
• Tuinonderhoud
• Groente kweken (ben reeds in bezit van een Farmbot)
• Huishoudelijk (stofzuigen, boodschappen)
• Beveiliging
• Energie (Tesla zonnetegels en Powerwall? )

Soms denk ik wel eens dat ik gek ben; dit lijkt zo'n kolossale taak, hoe begin je er in godsnaam aan?

Tot die tijd blijf ik me flink verdiepen in de materie. Tegen de tijd dat ik eraan kan beginnen zijn er waarschijnlijk alweer een boel dingen veranderd, verbeterd, of gestandaardiseerd. Misschien ook wel goedkoper. Als ik droom, droom ik in ieder geval wel groot

[matthijs33]

Patrick_v_L schreef op maandag 6 augustus 2018 @ 16:24:
Hallo allemaal,

Om te beginnen; Wow! Wat een topic en wat een bak aan voorbeelden, kennis en ervaring is hier samengebracht op Tweakers! Zelf ben ik veel bezig met IoT via Node-Red en de Chinese 5v modules op Arduino en ESP's. Maar dit forum heeft mij naar een ander level gebracht in mijn onderzoek voor mijn nieuwbouwhuis welke eind Q4 2019 opgeleverd gaat worden! (Standaard rijwoning)

Om te beginnen is de intentie nog niet om zo uitgebreid te gaan als Femme, maar ik ken mijzelf, ik begin met een klein plan en uiteindelijk hangt er RGBW via DMX in elk waterornament in de tuin ;-) Ik zal beginnen mijn plan/idee te posten met een paar 'aannames' waar ik op vastloop. Hopelijk heeft er iemand een moment om mij de juiste richting in te duwen!

Het plan om in het nieuwe huis te gaan doen
• Alle lichtpunten via een relay op de PLC d.m.v. een DO-kaart
• Alle schakelaars vervangen door druk-schakelaars via de PLC d.m.v. een DI-kaart
o 2/3 buttons per schakelaar, dat dimmende effect is wel super mooi!
o WC => Bewegingssensor
• TV-meubel zaken komen de relays achter het meubel te hangen, geschakeld vanaf de PLC d.m.v. een DO-kaart
• Electrische kachels schakelen via een relay op de PLC d.m.v. een DO-kaart
• 1-Wire om in elke kamer de temp te meten via "achter het klepje verscholen DS18B20 soldeertruckje"
• RGBW + DMX voor wat kleine sfeerverlichting aan de muur in de woonkamer later ook evt. tuinverlichting/keuken/trap

Wat ik nog wil uitzoeken;
• Wat voor vitrage/gordijnen ik ga nemen en met welke aansturing
• Hoe ik de warmtepomp van de vloerverwarming kan regelen (Moet ik eerst weten welke apparatuur er komt te hangen!)
• Water/Electra verbruik + Zonnepanelen kan uitlezen (Moet ik eerst weten welke apparatuur er komt te hangen!)
• Voorbereiding voor screen's/zonnescherm
• Of ik nog iets wil in de badkamer qua (DMX)licht en/of schakelingen
• Wat ik wil met Pir/Radar sensors
• Domotica pakket, voorkeur gaat nog wel naar IP-Symcon, ben van origine een PHP'ert
• En alles waar ik nog tegen aan ga lopen ;-)
Er komt meer detail op het moment dat ik alle technische tekeningen van het huis in bezit heb!

Dit alles wil ik laten aansturen door een WAGO PFC200 (750-8202) op een 24V din voeding.
Zelf heb ik voor deze gekozen na een klein onderzoekje rondom alle PLC's en WAGO modules.
• RS-232/-485 (switchable), handig voor DMX (aanname dat dit werkt!)
• Ondersteunt alle 750/753 WAGO modules
• HTML5 interface (eventueel voor de nood schakelingen), ben allergisch voor JAVA!

Mijn (test)setup zal worden;
• WAGO PFC200 (750-82020)
• 24V voeding
• DO-4 (750-504)
• DI-4 (750-402)
• Endmodule (750-600)
• 4 Relay's, ik denk de Finder Relay's
• 4 Lampen o.i.d. zodat het resultaat / de schakeling zichtbaar is
• Aangestuurd door RPI3 met IP-Symcon in de testmodus
• en natuurlijk netjes op rail klemmen afgemonteerd!

Paar aannames/vragen waar ik op blijf steken;

• De DO/DI-kaarten zijn er in 2/4/8/16 poort varianten. Nemen jullie de 4p variant omdat deze voor nog geen 10 euro stuk op ebay.de staan, of is het omdat de 16p variant kei onoverzichtelijk is qua bekabeling?

• Qua DI-kaarten kan je kiezen tussen een 3ms en een 0,2ms variant. Zien jullie problemen in het schakelen van de 3ms variant tov de 0,2ms?

• Qua de drukknoppen zweeft er ergens een scriptje rond om de waardes iets langer actief te houden zodat de polling vanuit bijv IPSym deze kan opvangen. Om het systeem te laten werken heb ik dus alleen een licentie van CodeSys PFC200 nodig om dit soort zaken in de PLC te programmeren? De WAGO software heb ik dus helemaal niet nodig?! (btw, ik heb nog te weinig onderzoek gedaan naar de MQTT module voor de PLC, dus ik blijf nog even op het poll systeem qua denken!)

• Iemand ervaring met de DMX op de ingebakken WAGO RS485 poort? Of uberhaubt via de WAGO? Deze vraag aangezien Femme dit via een los apparaat doet.

• Ik zie dat de WAGO niet direct beschreven kan worden om de status van een uitgang aan te sturen. Klopt mijn gedachten dat jullie hiervoor een registerveld gebruiken welke de PLC uitleest? IP-Symcon schrijft dan naar dit registerveld en de PLC pakt dit op? Moet dit toch zeker ook in de PLC geprogrammeerd worden via CodeSys?!

Dank alvast!

Groet Patrick

De 2, 4 en 8 poort kaarten hebben iets grotere terminals, wat toch wel gemakkelijker werkt. De 2 en 4 poort kaarten hebben ook 0 en 24V terminals, die kunnen ook gemakkelijk zijn om de schakelaars of relais van spanning te voorzien. Bij de 8 of 16 poort kaarten moet je de 0 of 24V ergens anders gaan zoeken. Maar als je een 16poort kaart op de kop kan tikken ergens, zou ik het niet laten, het neemt wel minder plaats in dan 4 4-poorts kaarten.

Ik heb zelf een 750-881 met een 750-652 kaart die ik gebruik voor DMX. Dit werkt goed. DMX werkt niet met een andere 750-65X kaart. Ik heb geen ervaring met de ingebouwde serial port op een PFC200. Het lijkt me de moeite waard het te proberen, en als het niet werkt kun je nog altijd een 750-652 bijkopen voor ~100€ op ebay.

Het verschil tussen de 3ms en de 0.2ms kaarten merk ik niet. Zou hier dan ook niet echt naar kijken bij de aankoop van kaarten.

Voor verschillende redenen zal je moeten programeren in de PLC zelf (ook al wil je de meeste logica op de RPI hebben), hiervoor is enkel de Codesys software niet genoeg (als ik me niet vergis, zo is het toch voor de 750-881) je hebt ook de Wago targets nodig. Als je problemen hebt de software werkende te krijgen, dan laat je het maar weten.

[MichVw]

Ik ben al even bezig met de implementatie van een hybride setup; basiszaken in PLC aangezien deze een hoge betrouwbaarheid heeft en dan via communicatie updates uitsturen naar een Domotica software packet en functionaliteit voorzien om in de PLC zelf ook zaken te gaan uitsturen via externe communicatie vanuit een Domotica software packet.

Alles werkt prima, updates stuur ik uit via MQTT vanuit de PLC en commando's naar de PLC zelf stuur ik via custom TCP packets.

Die laatste (custom TCP packets) zijn echter niet evident om te maintainen en zelfs in OpenHAB zit er een bug die m'n problemen bezorgd. In Home Assistant is er zelfs geen functionaliteit om custom TCP packets uit sturen.

Helaas vind ik geen MQTT library die kan subscriben voor CodeSys 2.3 waardoor ik nu toch meer en meer ga kijken naar een Wago PCF100 waar MQTT libraries voor bestaan met QOS1, ik vroeg me af of iemand een webshop kent waar deze min of meer betaalbaar is? Ik ben er me van bewust dat ik nog €100 zal moeten bijbetalen voor de licence voor Codesys 3.5. (Plus dan nog eens €50 voor de MQTT library)

[YorickErnst]

Is er al iemand in geslaagd om een stabiele MQTT connectie op te zetten met publishers en listeners op meer dan 1 topic en dit op een Wago PFC200?

Ik heb al verschillende opensource bibliotheken geprobeerd en zelfs de Janz Tec library aangeschaft van de Codesys Store in de hoop het werkend te krijgen, maar no luck. De officiële Wago MQTT library kost maar liefst 300 euro (zonder BTW) dus indien mogelijk vermijd ik die optie.

[YorickErnst]

@yniezink , ik kan je deze codesys mqtt library aanraden: https://github.com/stefandreyer
De developer heeft hem eergisteren volledig werkend gekregen en reageert zeer snel op issue die gerapporteerd worden..

Er zijn enkele dependencies die niet meteen duidelijk zijn, maar niets onoverkomelijk.

Ik ga ook de basis functies in de plc stoppen (3 x 16 kanaal inputs en 2 x 16 kanaal outputs). De plc zal continue controleren of hij verbinding kan maken met de mqtt broker. Als hij geen verbinding heeft dan is er een fall-back naar volledig autonome werking die ik in codesys programmeer.

[Giblet]

YorickErnst schreef op woensdag 26 september 2018 @ 12:39:
Ik ga ook de basis functies in de plc stoppen (3 x 16 kanaal inputs en 2 x 16 kanaal outputs). De plc zal continue controleren of hij verbinding kan maken met de mqtt broker. Als hij geen verbinding heeft dan is er een fall-back naar volledig autonome werking die ik in codesys programmeer.

Ik gebruik ook 1 van de inputs voor een dergelijke controle. Zolang deze hoog is, luistert de plc naar de domotica (bij mij via modbus, maar voor MQTT kan hetzelfde principe gelden natuurlijk). Mocht er dan onverhoopt iets niet goed zijn kan in het ergste geval altijd iemand het draadje doorknippen en neemt de PLC de meest bassale functies voor het licht aan en uit autonoom over.

[TailwindNL]

Hallo allemaal,

Ik lees al een tijdje mee en ben in het bezit van een Wago PFC200 met wat IO en Finder relais en ongeveer 6 km aan kabels die getrokken is door ons nieuwbouwhuis, maar ben nog niet begonnen aan mijn domoticaproject. Met Codesys/e!cockpit heb ik geen ervaring en ik merk dat het lastig is om te beginnen.

Mijn idee is vergelijkbaar met de plannen van andere mensen: De PLC de basis laten doen via een "nood"programma, in "normale"modus de signalering en het aansturen via MQTT (met Homeseer (heb ik nu), NodeRed, of een ander domoticapakket).

Wel wil ik de PLC via de onboard RS485 DMX sturing laten doen (naar de beroemde Ali DMX dimmers) en dat is meteen een behoorlijke opgave als je beginnend bent met PLC's, nieuw met Codesys, DMX en dan nog de OSCAT library. (als iemand dit al werkend heeft dan hoor ik het graag)

Nu zag ik bij Wago deze training https://www.wago.com/nl/e...cockpit-basis/evd00043034.

Mijn vraag is of iemand deze training heeft gedaan en wat de ervaring is? Is dit een goed vertrekpunt om te starten? Of zijn er andere/betere manieren?

ps. bij interesse zal ik een foto plaatsen van mijn hal waar alle elektra en data naartoe is gelegd ... of zoals men het meestal omschrijft: De touwtrek kermisattractie .

[YorickErnst]

Codesys is wat wennen, maar er is voldoende info online te vinden. Die cursus ziet er me weggesmeten geld uit. (Is wel heel erg basic). Beter is om enkele demo projecten te openen die anderen gemaakt hebben en te kijken hoe zij het doen.

Met DMX en seriele poorten heb ik geen ervaring en zie me hier ook niet meteen aan beginnen.

@Giblet : In jouw setup is er nog steeds fysieke interventie nodig (en wat voor een). Als je je PLC de mqtt broker laat pingen (of nog beter: de mqtt poort checkt) is dit volautomatisch zodra de ping faalt. Toch iets gebruiksvriendelijker en spaart een nieuwe kabel uit telkens er iets foutloopt

[Giblet]

YorickErnst schreef op dinsdag 2 oktober 2018 @ 12:25:
@Giblet : In jouw setup is er nog steeds fysieke interventie nodig (en wat voor een). Als je je PLC de mqtt broker laat pingen (of nog beter: de mqtt poort checkt) is dit volautomatisch zodra de ping faalt. Toch iets gebruiksvriendelijker en spaart een nieuwe kabel uit telkens er iets foutloopt

Ja en nee. Dat werkt inderdaad als de MQTT server ermee stopt. De domotica server (OpenHab in mijn geval), een MQTT schakelaar (Sonoff Touch bijvoorbeeld) kan er ook de brui aan geven. Die kun je uiteraard ook allemaal pingen, maar het pingbaar zijn van een server is niet hetzelfde als dat deze ook daadwerkelijk correct functioneert.

Ik heb al eens meegemaakt dat deze situatie voorkwam. En dat ontdek je altijd op zondagavond nadat je laat thuiskomt en geen zin hebt om uit te zoeken wat er aan de hand is. Even de meterkast open doen, een dupont kabeltje van 5cm doorknippen zodat je in elk geval normaal het licht aan kan doen wordt op dat moment erg gewaardeerd door mij en mijn vriendin. Het is dan ook niet voor niets een fallback scenario

Maar absoluut een goed idee die ik ga meenemen. Thanks!

[YorickErnst]

Giblet schreef op maandag 8 oktober 2018 @ 13:42:
[...]

Ja en nee. Dat werkt inderdaad als de MQTT server ermee stopt. De domotica server (OpenHab in mijn geval), een MQTT schakelaar (Sonoff Touch bijvoorbeeld) kan er ook de brui aan geven. Die kun je uiteraard ook allemaal pingen, maar het pingbaar zijn van een server is niet hetzelfde als dat deze ook daadwerkelijk correct functioneert.

Ik heb al eens meegemaakt dat deze situatie voorkwam. En dat ontdek je altijd op zondagavond nadat je laat thuiskomt en geen zin hebt om uit te zoeken wat er aan de hand is. Even de meterkast open doen, een dupont kabeltje van 5cm doorknippen zodat je in elk geval normaal het licht aan kan doen wordt op dat moment erg gewaardeerd door mij en mijn vriendin. Het is dan ook niet voor niets een fallback scenario

Maar absoluut een goed idee die ik ga meenemen. Thanks!

Idd, bij het falen van een onderdeel van domotica werkt dit niet, maar in dat geval kan ik dan (zelfs remote over vpn) de plc blocken met iptables en dan werkt hij ook weer autonoom tot ik het probleem heb opgelost. PS (Op zich is de netwerkkabel van de plc uittrekken al een fysieke bypass )

[DeadLock]

Femme schreef op donderdag 25 oktober 2018 @ 13:56:

Ik vind het persoonlijk heilloos om veel tijd te investeren in een failsafe. Je hebt het bijna nooit nodig en je beperkt jezelf enorm in de mogelijkheden. Het is wel handig om reservehardware op te plank te hebben liggen.

Wat betreft de industruino vraag ik me af of dit ding snel genoeg is en genoeg geheugen heeft om er serieuze dingen op te draaien. Biedt een RevolutionPi niet veel meer mogelijkheden?

Bedankt voor je reactie. Over het failsafe verhaal moet ik nog eens goed nadenken, en bespreken met de wederhelft.

Heel veel logica zal er niet geprogrammeerd moeten worden op de industruino denk ik. Het moet de eenvoudige I/O zelf afhandelen en daarover communiceren via mqtt (of ander protocol) met een Odroid of vergelijkbare mini-server die de domotica software zal draaien. Volgens mij moet de industruino wel in staat zijn om de input af te vangen, daarover te communiceren met mini-server (eventueel een commando te ontvangen) en de led drivers aan te sturen via DMX?

Een industruino kost 160 euro (130 + 30 voor ethernet shield) en geeft enkele analoge I/O en 8 digitale I/O (wat zeker te weinig is, dus ik heb er vermoedelijk 2 of 3 nodig). Jammer dat ie niet net wat meer DIO beschikbaar heeft.

Revolution PI ziet er ook wel een leuke optie uit! Als ik alles optel wordt het wel aardig duur (rev Pi a 235, een DIO module a 180, DMX module a 165 en een AIO module a 330). Dan wordt een reserve al erg duur!

Er zijn inderdaad niet zoveel led-lampen verkrijgbaar die op 24V werken. 24V constant voltage wordt voornamelijk gebruikt in led-strips die zijn uitgerust met weerstanden om de stroomsterkte te beperken. Naakte power leds stuur je aan met een constant current driver op een stroomsterkte van veelal 350mA of 700mA afhankelijk van de led. Constant current led-lampen met standaard fittingen zoals MR16 en AR111 zijn wel redelijk goed verkrijgbaar.

Hier ga ik best gewoon eens aan de slag met een meter of 2 (rgb)w led-strips om te kijken of dat eventueel bruikbaar is als hoofdverlichting. Er zijn schijnbaar talloze "armaturen" te verkrijgen die mooi in het plafond weggewerkt kunnen worden. Als sfeerverlichting zie je de led-strips wel vaker, als hoofdverlichting ben ik ze nog niet eerder tegen gekomen, maar mogelijk is het geen absurd idee .

Voor je elektriciën betekent dit dat ie buizen in stervorm van de verdeelkast naar de lichtpunten moet aanleggen (of naar het eerste lichtpunt in een lichtkring en vandoor hop je met je buis verder dan de volgende lichtpunten die in serie worden aangesloten).

Perfect, dat neem ik zeker mee. Met een centrale 24v/dmx led sturing is het de industruino/RevPi die de pulsen van de impulsschakelaars ontvangt en daarvan een DMX signaal maakt voor de led-drivers. Voor een alles-uit schakelaar moet ik ook (enkele) interruptoren (van groepen stopcontacten) aansturen, maar daar zal de elektricien wel raad mee weten hoop ik .

[Femme]

Ik ben dit weekend bezig geweest om MQTT aan de gang te krijgen op mijn Wago 750-881 voor het verzenden van berichten als een input wijzigt. Ik gebruikt hiervoor de MQTT library van Sebastian Rau. Via Mosquitto komen de berichtjes terecht in een MQTT module voor IP-Symcon die ik heb geschreven door het trucje af te kijken van deze module.

De communicatie werkt goed en betrouwbaar als er één input verandert, echter als ik een tegelijkertijd indrukken van twee knoppen wil herkennen komt het vaak voor dat er maar een berichtje wordt verstuurd voor één wijziging.

Ik gebruik R_TRIG en F_TRIG om een rising en falling edge te detecteren. Als dat gebeurt wordt de output Q true.

code:

PROGRAM PLC_PRG
VAR
    (* MQTT related *)
    M1: MQTT_Client;
    sTopic: STRING := 'Wago 750-881';
    sPayload: STRING := '';
    sIp : STRING := '192.168.1.1';
    sClientId : STRING := 'Wago750-881';
    iPortNumber : WORD := 1883;
    sUsername : STRING;
    sPassword : STRING;
    xPublish: BOOL := FALSE;
    xConnected : BOOL := FALSE;
    xBusy : BOOL := FALSE;

    DI0_RTRIG : R_TRIG;
    DI0_FTRIG : F_TRIG;
    DI0_TOF : TOF;
    DI1_RTRIG : R_TRIG;
    DI1_FTRIG : F_TRIG;
    DI1_TOF : TOF;
    DI2_RTRIG : R_TRIG;
    DI2_FTRIG : F_TRIG;
    DI2_TOF : TOF;
    
END_VAR

code:

xPublish := FALSE;

IF NOT xBusy THEN
    sPayload := '';
END_IF

DI0_RTRIG(CLK := %IX22.0);
DI0_FTRIG(CLK := %IX22.0);

IF DI0_RTRIG.Q THEN
    xPublish := TRUE;
    sPayload := CONCAT(sPayload, '"DI01.1":');
    sPayload := CONCAT(sPayload, BOOL_TO_STRING(%IX22.0));
    sPayload := CONCAT(sPayload, ',');
END_IF

IF DI0_FTRIG.Q THEN
    xPublish := TRUE;
    sPayload := CONCAT(sPayload, '"DI01.1":');
    sPayload := CONCAT(sPayload, BOOL_TO_STRING(%IX22.0));
    sPayload := CONCAT(sPayload, ',');
END_IF

DI0_TOF(IN:= %IX22.0,PT:= t#650ms);
%MX0.0 := DI0_TOF.Q;

DI1_RTRIG(CLK := %IX22.1);
DI1_FTRIG(CLK := %IX22.1);

IF DI1_RTRIG.Q THEN
    xPublish := TRUE;
    sPayload := CONCAT(sPayload, '"DI01.2":');
    sPayload := CONCAT(sPayload, BOOL_TO_STRING(%IX22.1));
    sPayload := CONCAT(sPayload, ',');
END_IF

IF DI1_FTRIG.Q THEN
    xPublish := TRUE;
    sPayload := CONCAT(sPayload, '"DI01.2":');
    sPayload := CONCAT(sPayload, BOOL_TO_STRING(%IX22.1));
    sPayload := CONCAT(sPayload, ',');
END_IF

DI1_TOF(IN:= %IX22.1,PT:= t#650ms);
%MX0.1 := DI1_TOF.Q;

DI2_RTRIG(CLK := %IX22.2);
DI2_FTRIG(CLK := %IX22.2);

IF DI2_RTRIG.Q THEN
    xPublish := TRUE;
    sPayload := CONCAT(sPayload, '"DI01.3":');
    sPayload := CONCAT(sPayload, BOOL_TO_STRING(%IX22.2));
    sPayload := CONCAT(sPayload, ',');
END_IF

IF DI2_FTRIG.Q THEN
    xPublish := TRUE;
    sPayload := CONCAT(sPayload, '"DI01.3":');
    sPayload := CONCAT(sPayload, BOOL_TO_STRING(%IX22.2));
    sPayload := CONCAT(sPayload, ',');
END_IF

DI2_TOF(IN:= %IX22.2,PT:= t#650ms);
%MX0.2 := DI2_TOF.Q;


M1(
    sTopic      := sTopic,
    sPayload    := sPayload,
    sIp         := sIp,
    sClientId   := sClientId,
    iPortNumber := iPortNumber,
    sUsername := sUsername,
    sPassword := sPassword,
    xPublish    := xPublish,
    xConnected => xConnected,
    xBusy => xBusy
);

En dat dan voor in totaal 96 inputs.
Die TOF (time off-delay) zit erin vanwege modbus polling.
De berichtje die verstuurd worden hebben bijv. de volgende payload:

code:

"DI13.1":TRUE,

of als er in één cyclus meerdere triggers zijn:

code:

"DI13.1":TRUE,"DI13.2":TRUE,

Voor een enkele druk op een knop werkt het als een trein en merk ik dat de responstijd een stuk beter is dan via modbus polling. Als ik twee knoppen tegelijkertijd indruk dan komt het vaak voor de rising edge wel gedetecteerd wordt maar de falling edge van één van de twee knoppen niet. Die input blijft dan hangen in IP-Symcon omdat ik geen bericht krijg over de de falling edge.

Iemand tips over hoe dit opgelost kan worden? Is mijn plc te traag en zorgt het versturen van een MQTT bericht ervoor dat een falling edge niet gedetecteerd wordt?

Nog een andere vraag: hoe escape ik curly brackets (een { of } ) in een string? Ik zou graag valide json als payload willen versturen.

edit:
Edit: de oplossing bleek gelukkig eenvoudig. De xBusy-variabele is er kennelijk om aan te geven dat het MQTT functieblok bezig is met verzenden. De payload moet bij een nieuwe cyclus dus niet leeggemaakt worden als xBusy true is. Dit heb ik toegevoegd in het bovenstaande codevoorbeeld.

[ Voor 13% gewijzigd door Femme op 07-01-2019 19:16 ]

[Femme]

raymonvdm schreef op maandag 7 januari 2019 @ 15:08:
Ik heb het nog niet helemaal goed voor elkaar om de PLC in Domoticz of HomeAssistant werkend te krijgen. HomeAssistant ziet de PLC wel en inputs wijzigen ook. Maar de polling interval is heel hoog en lijkt niet instelbaar.

Via NodeRed werkt het wel en kan ik wel een poll interval opgeven van 200ms. Dus daar is een work-arround voor te maken.

Heb je MQTT al als alternatief al geprobeerd? Zoek op mqtt in dit topic en je krijgt voorbeeldcode.

Omdat de 750-414 modules nog vrij prijzig zijn heb ik voor nu eerst een 8 voudige PNP opto-coupler besteld bij AliExpress en een aantal 705-501 output modules. Als die binnen zijn kan ik weer verder met de PLC POC om te zien of ik wel outputs kan schakelen.

Ik heb ze destijds voor weinig van eBay kunnen halen, maar je moet er geluk mee hebben omdat een 750-414 een stuk zeldzamer is dan een normale 24V inputmodule.

[Femme]

raymonvdm schreef op maandag 7 januari 2019 @ 15:52:
Ik kan niet programmeren, en heb ook nog niet ontdekt hoe ik de PLC moet programmeren. Codesys2.x wel geinstalleerd maar toen was ik helemaal de weg kwijt

Ok ik zal eens kijken of ik binnenkort wat instructies kan maken. Ik begrijp zelf ook geen halve hol van Codesys en Structured Text, maar met wat klungelen is het toch gelukt om mqtt berichtje uit mijn plc te krijgen .

[WebStarVenlo]

Zelf heb ik een andere oplossing bedacht om vanuit de PLC de verschillende inputs te detecteren en door te sturen via MQTT.
Ik maak gebruik van de zelfde MQTT library.

Door een queue te maken van berichten heb ik ondervangen dat als er meerdere inputs wijzigen, alle berichten na elkaar verstuurd worden.

Hiervoor heb ik een aantal functie blokken gemaakt en wat globale variables.

Globale variables:

code:

VAR_GLOBAL
    (*MQTT Settings / variables*)
    MQTT_IP: STRING := '192.168.0.2';
    MQTT_PORT: WORD := 1883;
    MQTT_CLIENT_ID: STRING := '1234';
    MQTT_USER: STRING;
    MQTT_PASS: STRING;
    MQTT_MESSAGE_QUEUE: ARRAY[1..20] OF MQTT_MESSAGE; (*Array to store the outgoing messages, extend the size if more messages need to be stored*)
    MQTT_MESSAGE_QUEUE_SIZE: USINT := 20; (*message queue length*)
    MQTT_MESSAGE_QUEUE_CURRENT: USINT := 0; (*used for sending, the current message in the queue that is processed*)
    MQTT_MESSAGE_QUEUE_LAST: USINT := 0; (*the last added message in the queue*)
    MQTT_SEND : MQTT_SEND;
END_VAR

Data type:

code:

TYPE MQTT_MESSAGE :
STRUCT
    Topic: STRING;
    Payload: STRING;
    DateTime: DT;
END_STRUCT
END_TYPE

FB om de berichten daadwerkelijk te verzenden, wordt aangeroepen op het laatst van het main programma

code:

(*HEADER*)
FUNCTION_BLOCK MQTT_HANDLER
VAR_INPUT
END_VAR
VAR_OUTPUT
END_VAR
VAR
    MQTT_Client : MQTT_Client;
    Message: MQTT_Message;
END_VAR
VAR_IN_OUT
END_VAR
VAR RETAIN
    Connected: BOOL;
    Busy: BOOL;
    Publish: BOOL;
    SkipCycle: BOOL;
END_VAR

(*BODY*)
IF NOT SkipCycle AND NOT Publish AND NOT Busy AND  MQTT_MESSAGE_QUEUE_CURRENT <> MQTT_MESSAGE_QUEUE_LAST THEN
    MQTT_MESSAGE_QUEUE_CURRENT := MQTT_MESSAGE_QUEUE_CURRENT + 1;

    IF MQTT_MESSAGE_QUEUE_CURRENT > MQTT_MESSAGE_QUEUE_SIZE THEN
        MQTT_MESSAGE_QUEUE_CURRENT := 1;
    END_IF

    Message := MQTT_MESSAGE_QUEUE[MQTT_MESSAGE_QUEUE_CURRENT];
    Publish := TRUE;
    SkipCycle := TRUE;
END_IF

IF NOT Publish AND SkipCycle THEN
    SkipCycle := FALSE;
END_IF

MQTT_Client(
    sTopic:= Message.Topic,
    sPayload:= Message.Payload,
    sIp:= MQTT_IP,
    sClientId:=MQTT_CLIENT_ID,
    iPortNumber:= MQTT_PORT,
    sUsername:= MQTT_USER,
    sPassword:= MQTT_PASS,
    xPublish:= Publish,
    xConnected=> Connected,
    xBusy=> Busy);

FB om een bericht aan de queue toe te voegen

code:

(*HEADER*)
FUNCTION_BLOCK MQTT_SEND
VAR_INPUT
    Topic : STRING;
    Payload: STRING;
END_VAR
VAR_OUTPUT
END_VAR
VAR
    Message: MQTT_MESSAGE;
END_VAR

(*BODY*)
MQTT_MESSAGE_QUEUE_LAST := MQTT_MESSAGE_QUEUE_LAST + 1;
IF MQTT_MESSAGE_QUEUE_LAST > MQTT_MESSAGE_QUEUE_SIZE THEN
    MQTT_MESSAGE_QUEUE_LAST := 1;
END_IF

Message.Topic := Topic;
Message.Payload := Payload;
Message.DateTime := SysRtcGetTime(TRUE);

MQTT_MESSAGE_QUEUE[MQTT_MESSAGE_QUEUE_LAST] := Message;

En het main programma met de logica / aanroep

code:

(*call to add new message to the queue*)
MQTT_SEND(Topic:= 'home/floor-0/livging-room/switch/dining-table-lights', Payload:='message content');

MQTT_SEND(Topic:= 'home/floor-0/livging-room/switch/dining-table-lights', Payload:='next message');

MQTT_HANDLER();

De enige beperking aan deze manier van verzenden is de lengte van de queue, als er meer en sneller berichten in de queue geplaatst worden dan dat deze worden verzonden zullen niet verzonden berichten worden overschreven.

Dit is wel redelijk te voorkomen door de lengte van de queue groter te maken, deze kan nu maximaal 20 berichten bevatten, maar kan gewenst groter worden gemaakt.
Voor mij is dit ruim voldoende, de kans dat er 20 schakelaars en/of deurcontacten gelijktijdig worden aangesproken lijkt me onwaarschijnlijk.

[Femme]

WebStarVenlo schreef op maandag 7 januari 2019 @ 20:43:
Zelf heb ik een andere oplossing bedacht om vanuit de PLC de verschillende inputs te detecteren en door te sturen via MQTT.
Ik maak gebruik van de zelfde MQTT library.

Door een queue te maken van berichten heb ik ondervangen dat als er meerdere inputs wijzigen, alle berichten na elkaar verstuurd worden.

Hiervoor heb ik een aantal functie blokken gemaakt en wat globale variables.

Mooie oplossing!

Het voordeel van jouw oplossing is inderdaad wel dat elke input onder zijn eigen topic kan publishen. Een theoretisch nadeel is dat er wat meer vertraging in de verzending zit als de message queue langer is dan één bericht.

Ik hou het maar even bij wat ik nu gebakken heb. Het is de snelste oplossing en heeft ook minder verwerkingstijd nodig aan de kant van de ontvanger. Het decoderen van berichtjes heb ik zelf in de hand met mijn MQTT Topic module voor IP-Symcon. Dat ziet er zo uit:



MQTT Client configuratieformulier:



Vervolgens heb ik een Double Push Button module gemaakt. Een instantie heeft twee variabelen als input en bepaalt aan de hand van welke variabele van waarde verandert en hoe lang dat duurt of er een single of double en short of long press plaatsvindt:





Andere module-instanties en trigger events kunnen weer op reageren op veranderingen van de onderliggende variabelen van een Push Button instantie. De module werkt onafhankelijk van de achterliggende hardware zolang die maar snel en accuraat waardeveranderingen van een input kan doorgeven. Kan met modbus (maar niet 100% betrouwbaar) maar ook met bijv. een Railduino.

[ Voor 7% gewijzigd door Femme op 08-01-2019 11:22 ]

[Sandolution]

Femme schreef op maandag 7 januari 2019 @ 16:00:
[...]


Ok ik zal eens kijken of ik binnenkort wat instructies kan maken. Ik begrijp zelf ook geen halve hol van Codesys en Structured Text, maar met wat klungelen is het toch gelukt om mqtt berichtje uit mijn plc te krijgen .

Femme, ik help je hier graag bij. Werk dagelijks met CoDeSys en ST.
Ben nu bezig met een libraray om Domoticz te koppelen met CoDeSys via JSON/HTTP, maar ga ook testen met de CoDeSys V3 library van Stefandryer (https://github.com/stefandreyer/CODESYS-MQTT)

[ Voor 19% gewijzigd door Sandolution op 09-01-2019 12:41 ]

[SuperJoker]

Een paar losse dingen:

1) de vraag of domoticz het kan. Ik lees dat Femme bezig is met MQTT. Dat wordt door domoticz ondersteund. Dus als dat spul 'MQTT kan', dan werkt het met domoticz
2) Femme, ik vond je huis prachtig en je installatie ook. Echter het eerste wat ik mij afvroeg is wat het aan stroom verbruikt. Je gaf eerder in dit topic '10 Watt' aan. Hoewel ik je historisch érg hoog heb zitten, geloof ik daar geen moer van. Het totaalverbruik van jouw domotica installatie ligt volgens mij ver boven de 100Watt, zo niet grof meer.

Wat ik juist dacht bij dat filmpje is; wat zal Femme nu balen van de ontwikkelingen. Want het had allemaal goedkoper, compacter en veel makkelijker gekund met de hedendaagse spullen. Wireless, maar toch betrouwbaar. Zefs in de industrie is de PLC al jaren op z'n retour, en eigenlijk al weg, daar nagenoeg alles wat tegenwoordig industrieel als PLC wordt weggezet, helemaal geen PLC meer is.

Nogmaals een prachtige installatie en mooie techniek, zonder meer, maar héél erg custom; denk bv. ook aan de verkoopwaarde van je huis. Nu zal Femme niet snel verhuizen gok ik en dat voor hem minder van belang zijn, maar geen hond wil dit soort custom installaties in z'n koophuis waarbij de kennishouder de verkoper is die verder niet support.

Anno 2019 zou er geen haar op mijn hoofd zijn die er aan dacht om - in een situatie waar er nog niets is - deze oplossing te gebruiken. Veel te duur (wederom, naar verhouding), veel te hoog stroomverbruik en op geen enkele manier een standaard (voor woonhuizen). Plus bakken vol kabels trekken.

Pak dan gewoon zigbee. Dat werkt probleemloos, omdat het een mesh netwerk is is bereik geen probleem, het is standaard en je hoeft er niets aan kabels voor te trekken. En voor alles is een werkende oplossing te vinden, en alle domotica pakketten ondersteunen het standaard. Ga je nieuwbouwen, zou ik gewoon KNX pakken, dat is momenteel nu eenmaal de standaard. Werkt gewoon prima en je kunt er reguliere support op krijgen.

Nogmaals; lees dit aub niet als een aanval. Ik vind de installatie prachtig, bijna kunst, ook hoe de bekabeling is gedaan, zeer mooi uitgevoerd. Maar zou ik dat huis kopen met die installatie erin? Wellicht. Als de eigenaar beloofde die hele installatie te verwijderen en werkende normale bekabeling zou installeren.

[ Voor 3% gewijzigd door SuperJoker op 09-01-2019 15:48 ]

[jacquesmulders]

ook ik heb een mooi setje in duitsland weten te bemachtigen.

controller wel een oudje, 6x 8DI 6x 8DO 1x 4AI 0-10v 1x 4AO 0-10v en nog een 750-602. voor zn 170 euro
nog 6x 4AO 0-10v via marktplaats gekocht.

zo kan ik eea makkelijk dimmen, alles via een test opstelling in openhab gemaakt.

de code van @jellevictoor gebruikt en hier en daar wat aangepast om de DI via MQTT te verzenden:
zie post van Jelle:

jellevictoor schreef op woensdag 21 juni 2017 @ 22:30:

PLC_PRG VAR

code:

PROGRAM PLC_PRG
VAR
    button_001: BUTTON;

    mqttClient: MQTT_Client;
        payload:STRING;
           topic:STRING;
            Ip: STRING := '192.168.1.117';
            PortNumber: WORD := 1883;
            Clientid: STRING := 'WAGO 750-881';
            Username: STRING := '';
            Password: STRING := '';
            pub: BOOL;
        Connected: BOOL;
END_VAR

PLC_PRG

code:

pub:=FALSE;
payload:='';
topic:='';

IF Connected THEN

button_001(IN:=DI1, INPUT:=1, SWITCH:=TRUE, topic:=topic, payload:=payload, pub:=pub);

END_IF

mqttClient(
       sTopic:= topic,
       sPayload:= payload,
       sIp:= Ip,
       iPortNumber:= PortNumber,
        sClientid:= Clientid,
       xPublish:= pub,
    xConnected=>Connected);

BUTTON FB VARS

code:

FUNCTION_BLOCK BUTTON
VAR_INPUT
    IN: BOOL;
    INPUT: INT;
    SWITCH: BOOL;
END_VAR
VAR_INPUT CONSTANT
    PT : TIME := t#600ms;
END_VAR
VAR_IN_OUT
    pub: BOOL;
    topic: STRING;
    payload: STRING;
END_VAR
VAR_OUTPUT

END_VAR
VAR
    tx:TP;
    CNT: INT:=0;
    edge: BOOL:=FALSE;
    long: BOOL:=FALSE;
    Count: BOOL:=FALSE;
END_VAR

BUTTON FB

code:

IF NOT SWITCH AND NOT pub THEN
    IF IN AND NOT Count THEN
        payload := 'ON';
        Count:=TRUE;
        pub:=TRUE;
    ELSIF NOT IN AND Count THEN
        payload := 'OFF';
        Count:= FALSE;
        pub := TRUE;
    END_IF
    IF pub THEN
        topic:='/WAGO/DI';
        topic := CONCAT(topic, INT_TO_STRING(INPUT));
    END_IF
ELSIF NOT pub THEN
    tx(IN:=IN,PT:=PT);
    IF IN THEN
        IF NOT tx.Q THEN
            IF CNT = 0 THEN
                payload := 'long';
                pub:=TRUE;
                long:=TRUE;
                tx(IN:=FALSE,PT:=PT);
                tx(IN:=IN,PT:=PT);
            END_IF
        END_IF
    ELSIF tx.Q AND edge THEN
        IF NOT long THEN
            cnt := cnt +1;
        END_IF
        long:=FALSE;
    END_IF
    IF NOT tx.Q AND cnt > 0 THEN
        pub:=TRUE;
        payload := INT_TO_STRING(cnt);
        cnt := 0;
    END_IF
    edge := IN;
    IF pub THEN
        topic:='/WAGO/DI';
        topic := CONCAT(topic, INT_TO_STRING(INPUT));
    END_IF
END_IF

- ik kan in main program aangeven of het een wand schakelaar is, voor de 1,2 of long pushes, of dat het een sensor is, met alleen een ON/OFF status.
- publish topic wordt bepaald aan de hand van INPUT
- ik vind de code zo iets overzichtelijker en makkelijker uit te breiden.
- als mqtt niet connected is kijkt hij ook niet naar de schakelaars
- eea makkelijk uit te breiden dmv "button" te kopieren ik heb nu 48 buttons er in zitten

[ Voor 10% gewijzigd door jacquesmulders op 14-01-2019 22:43 ]

[BoschR]

Of dit helemaal het juist topic is weet ik niet. Ik zit met de volgende situatie:

Ik heb een schuur en caport die een meter of 8-9 van het huis af staan. De lampen / garagedeur kan ik al (groten)deels aansturen vanuit Domoticz, maar dit werkt allemaal net niet even smooth (door met name de afstand). Ik gebruik hier zowel Zwave (Fibaro plug), Wifi/MQTT (Shelly1), Zigbee (Aqara PIR) en KAKU voor. Juist een hele hoop verschillende protocollen.

Ik heb een router ingericht als accespoint die nu nog bij de achterdeur staat waardoor het WIFI signaal sterk is verbeterd bij de garage/schuur (Shelly1 werkt feilloos). Maar ook heb ik een UTP kabel (ondergronds) lopen naar de schuur. De bedoeling is om het accespoint daarheen te verplaatsen. Maar ook bied dit natuurlijk andere mogelijkheden.

Graag wil ik alles reduceren naar 1 oplossing, zodat ik niet elk netwerk (Zwave, Zigbee, KAKU, ..) daarheen te hoef uitbreiden. Wat ik wil aansturen:

• Gargedeur (pulsdrukker)
• Deur contact (controle of de garagedeur dicht is)
• Caport verlichting
• Caport bewegingssensor
• Schuur bewegingssensor
• Schuur verlichting
• Tuinverlichting (links/rechts apart aan te sturen)

Zonder al te veel kennis van zaken kom ik op: 5x relay en 3x input.

Ik zat zelf te denken aan een Railduino, maar ik ben zelf totaal nieuw op dit gebied. Dus ben benieuwd of jullie wellicht ideeën of adviezen hebben. Wie kan me hierbij (op weg) helpen?

[Fraggar]

Is er iemand die weet hoe Siemens plc's zich verhouden t.o.v. Wago? Op het gebied van software/programmeren, nieuw en tweedehands prijzen, en beschikbaarheid tweedehands?

Ik zie op de Siemens website dat er een specifieke mqtt-module bestaat die me interessant lijkt: https://support.industry....imatic-cpu?dti=0&lc=en-US

[MichVw]

Femme schreef op maandag 7 januari 2019 @ 09:17:
Ik ben dit weekend bezig geweest om MQTT aan de gang te krijgen op mijn Wago 750-881 voor het verzenden van berichten als een input wijzigt. Ik gebruikt hiervoor de MQTT library van Sebastian Rau. Via Mosquitto komen de berichtjes terecht in een MQTT module voor IP-Symcon die ik heb geschreven door het trucje af te kijken van deze module.

Ik heb iets gelijkaardig gemaakt met het verschil dat er nog eens FB's tussenzitten van OSCAT waardoor aan de hand van drukknoppen door de PLC zowel een enkele, dubbele als lange druk op de drukknop kan herkennen. Zo heeft kan je aan een simpele drukknop meerdere functies gaan hangen (bv, dubbele druk = alle lichten uit in die ruimte). Die events worden allemaal doorgestuurd via MQTT, leuk om iets meer mee verder te doen in een slimmere laag van je setup. De library van Sebastian Rau is prima, ik had zelfde probleem als jij maar met wat hulp van Sebasian zelf heb ik nu wel een betrouwbare implementatie. Indien je interesse hebt wil ik de implementatie gerust delen.

Zelf ben ik wel overgestapt naar een PFC200 (op de kop getikt voor €250 ) aangezien de library van Sebastian enkel QOS 0 ondersteund en geen MQTT subscriptions. akkoord die QOS zou geen probleem mogen geven aangezien het netwerk verkeer tussen je PLC en Odroid's waarschijnlijk zeer beperkt is. Voor mij zijn de subscriptions wel een must aangezien ik naar een volledige redundante setup wil gaan waar de PLC ook helemaal zelfstandig kan opereren zonder Odroid/Rpi/... , hoe je het ook draait of keert: een PLC blijft elektronisch gezien de betrouwbaarste/meest robuuste component. Succes!

[deWit]

Femme schreef op dinsdag 8 januari 2019 @ 11:19:
[...]


Het decoderen van berichtjes heb ik zelf in de hand met mijn MQTT Topic module voor IP-Symcon. Dat ziet er zo uit:

[Afbeelding: MQTT topic]

MQTT Client configuratieformulier:

[Afbeelding: MQTT client]

Heb je zelf een MQTT cliënt geschreven als module voor IP Symcon of gebruik gemaakt van 1 van de bestaande die her en der te vinden zijn? Ik krijg het niet stabiel draaiend... Continu buffers die vol lopen of verbindingen die eruit schieten...

[Femme]

deWit schreef op woensdag 30 januari 2019 @ 21:35:
[...]


Heb je zelf een MQTT cliënt geschreven als module voor IP Symcon of gebruik gemaakt van 1 van de bestaande die her en der te vinden zijn? Ik krijg het niet stabiel draaiend... Continu buffers die vol lopen of verbindingen die eruit schieten...

Ik heb me laten inspireren door deze module: https://github.com/Schnittcher/IPS-KS-MQTT

De mijne is nog een proof of concept. Het connecten/reconnecten bij opstarten of wegvallen van de verbinding moet nog geautomatiseerd worden. Als de verbinding is opgezet loopt ie stabiel.

[mpdevries84]

Hoi MichVw,

Ik ben met iets soortgelijks als jij bezig, OSCAT en een PFC200. Loop nu een aantal dagen te stoeien met een juiste implementatie van een juiste MQTT library, de OSCAT Function Blocks etc maar kom er nog niet helemaal lekker uit. Je geeft aan nu een betrouwbare implementatie te hebben en dat je deze zou willen delen. Zou je dat willen doen? Als ik een goed begin heb gaat me dat heel erg op weg helpen

MichVw schreef op vrijdag 25 januari 2019 @ 20:06:
[...]


Ik heb iets gelijkaardig gemaakt met het verschil dat er nog eens FB's tussenzitten van OSCAT waardoor aan de hand van drukknoppen door de PLC zowel een enkele, dubbele als lange druk op de drukknop kan herkennen. Zo heeft kan je aan een simpele drukknop meerdere functies gaan hangen (bv, dubbele druk = alle lichten uit in die ruimte). Die events worden allemaal doorgestuurd via MQTT, leuk om iets meer mee verder te doen in een slimmere laag van je setup. De library van Sebastian Rau is prima, ik had zelfde probleem als jij maar met wat hulp van Sebasian zelf heb ik nu wel een betrouwbare implementatie. Indien je interesse hebt wil ik de implementatie gerust delen.

Zelf ben ik wel overgestapt naar een PFC200 (op de kop getikt voor €250 ) aangezien de library van Sebastian enkel QOS 0 ondersteund en geen MQTT subscriptions. akkoord die QOS zou geen probleem mogen geven aangezien het netwerk verkeer tussen je PLC en Odroid's waarschijnlijk zeer beperkt is. Voor mij zijn de subscriptions wel een must aangezien ik naar een volledige redundante setup wil gaan waar de PLC ook helemaal zelfstandig kan opereren zonder Odroid/Rpi/... , hoe je het ook draait of keert: een PLC blijft elektronisch gezien de betrouwbaarste/meest robuuste component. Succes!

[MichVw]

mpdevries84 schreef op donderdag 21 februari 2019 @ 14:52:
Hoi MichVw,

Ik ben met iets soortgelijks als jij bezig, OSCAT en een PFC200. Loop nu een aantal dagen te stoeien met een juiste implementatie van een juiste MQTT library, de OSCAT Function Blocks etc maar kom er nog niet helemaal lekker uit. Je geeft aan nu een betrouwbare implementatie te hebben en dat je deze zou willen delen. Zou je dat willen doen? Als ik een goed begin heb gaat me dat heel erg op weg helpen


[...]

Hey,

geen probleem, stuur me een berichtje met je mailadres en dan stuur ik je het project.
Graag niets publiceren aangezien ik dat graag zou doen éénmaal ik subscribe er ook inzitten heb..

Manier waarop het werkt is vrij eenvoudig;

• Digital input FB die een single, double of long press detecteerd en daarop een uitgang hoog maakt voor één cyclus (single, double, long event output)
• Digital output FB die kan aangestuurd worden aan de hand van de events van de Digital input FB's
• Beide bovenstaande FB's hebben een referentie in hun creatie meegekregen naar een queue waar ze dan events op publishen, voor een input FB is dat een single, double, long event voor een output FB is dat een event wanneer de output verandert van state
• In een appart program met lagere prio worden de MQTT events verstuurd naar de broker, omdat dit een appart program is met lagere prio is er geen impact mogelijk tussen je MQTT functionaliteit en je basic PLC operations

Subscribe bekijk ik in de volgende weken/maanden, waarschijnlijk ga ik gewoon een boolean hoog maken voor één cyclus wanneer een waarde binnenkomt en die boolean kan dan weer gekoppeld worden aan de inputs van de outputs FB om zaken mee te gaan schakelen.

Ik post hier wel een bericht als ik alles werkend heb met de link naar m'n git.

[ Voor 6% gewijzigd door MichVw op 03-03-2019 12:22 ]

[Heire]

Momenteel bezig met alle bekabeling te leggen, maar ben er nog niet helemaal uit voor de PLC welke ik zou nemen. Uiteindelijk zal ik de PLC voor basis functionaliteit gebruiken en eventueel ook voor DMX, bedoeling is om toch de basis zaken te programmeren en de rest binnen Home Assistant verder op te vangen. Na veel opzoekwerk ben ik alleen aan het twijfelen geweest voor de 750/PFC100/PFC200, uiteindelijk ga ik liever voor de nieuwe CodeSys V3 omgeving en omdat deze reeds MQTT ondersteunt, daarom denk ik volgende items te kopen maar had graag jullie input hierover wat jullie ervan denken:
- 750-8101 PFC100. PFC200 lijkt me wat overkill voor thuis gebruik. Wat denken jullie?
- 750-600 eind module
- 750-430 of 750-1405 DI
- 750-530 of 750-1504 DO
- CODESYS Control for PFC100 SL

Klopt het dat als ik de PLC apart met de Codesys control aankoop dat ik volledige configuratie kan doen?
Maakt het uit of de PLC second hand aankoopt tov nieuw om licenties te kunnen koppelen?

[MichVw]

Heire schreef op zaterdag 4 mei 2019 @ 21:42:
Momenteel bezig met alle bekabeling te leggen, maar ben er nog niet helemaal uit voor de PLC welke ik zou nemen. Uiteindelijk zal ik de PLC voor basis functionaliteit gebruiken en eventueel ook voor DMX, bedoeling is om toch de basis zaken te programmeren en de rest binnen Home Assistant verder op te vangen. Na veel opzoekwerk ben ik alleen aan het twijfelen geweest voor de 750/PFC100/PFC200, uiteindelijk ga ik liever voor de nieuwe CodeSys V3 omgeving en omdat deze reeds MQTT ondersteunt, daarom denk ik volgende items te kopen maar had graag jullie input hierover wat jullie ervan denken:
- 750-8101 PFC100. PFC200 lijkt me wat overkill voor thuis gebruik. Wat denken jullie?
- 750-600 eind module
- 750-430 of 750-1405 DI
- 750-530 of 750-1504 DO
- CODESYS Control for PFC100 SL

Klopt het dat als ik de PLC apart met de Codesys control aankoop dat ik volledige configuratie kan doen?
Maakt het uit of de PLC second hand aankoopt tov nieuw om licenties te kunnen koppelen?

Ik heb een PFC200 maar zie geen reden waarom een PFC100 niet voldoende zou zijn (ik kon de mijne op kop tikken met wat geluk, anders had ik waarschijnlijk ook een PFC100).
Voor MQTT library is dit echt een aanrader: https://github.com/stefandreyer/CODESYS-MQTT
Mijn implementatie werkt ook met de kern logica in de PLC zelf en stuurt dan events via MQTT naar Home-Assistant, ik ben er bijna klaar mee en publiceer het boeltje dan.

PLC is één aankoop, licentie een andere.. maakt niet uit of ie tweedehands is..

Succes!

[MichVw]

Vraagje:

Ik ben aan het kijken hoe je shades kan automatiseren, dit is een leuk voorgewerkt voorbeeld van een DIY oplossing: YouTube: DIY Motorized Roller Shades + Wireless MQTT Smart Home Integration

Er word echter wel gebruik gemaakt van een wifi enabled MCU met MQTT, leuk maar ik vind een kabel nog altijd beter.

Ik vroeg me af of er hier mensen zijn die hun zonnewering/gordijnen geautomatiseerd hebben en wat jullie ervaringen zijn? Voorwaarde is natuurlijk dat de sturing van de automatisatie integreerd met home automation software zoals OpenHab, HomeAssistant, Domoticz..

[Verwijderd]

Hallo allemaal,

Na lang lezen en proberen wou ik jullie vragen om hulp.
Ik heb een Wago Starterkit aangeschaft met een PFC100 (750-810) en de e!cockpit software
Ik heb een beetje ervaring met plc programmeren via ladder diagram en dacht dit allemaal zo ff te fixen. Dit valt me toch allemaal een beetje tegen!

Ik kan hele logica's in de plc er wel in kloppen en de intentie is om al het belangrijke in huis te kunnen blijven schakelen dmv pulsdrukkers. Dit heb ik wel zo goed als voor elkaar.

Nu heb ik een Raspberry Pi met daarop Hass.io en daarop ook de Mosquitto MQTT broker geïnstalleerd
Hier wil ik via node-red over MQTT een output op de plc schakelen.

ik heb al zitten prutsen met al die libraries maar ik krijg er geen data in of uit.
vanaf firmware 12 heeft de wago ingebouwde cloud connectivity vanuit het web management kan ik wel verbinding maken met de MQTT broker.

is er iemand die mij weer op gang kan helpen?

[YorickErnst]

Verwijderd schreef op woensdag 8 mei 2019 @ 15:08:

ik heb al zitten prutsen met al die libraries maar ik krijg er geen data in of uit.
vanaf firmware 12 heeft de wago ingebouwde cloud connectivity vanuit het web management kan ik wel verbinding maken met de MQTT broker.

is er iemand die mij weer op gang kan helpen?

Zoals hierboven vermeld kijk je best hier eens: https://github.com/stefandreyer
Dat is een stabiele library met enkele dependencies (OSCAT) maar niets onoverkomelijks.

De developer is er vooral actief mee bezig en is zeer responsief op bug en feature requests.

[Hobbles]

Na enkele maanden experimenteren met de PFC200 van Wago, heb ik uiteindelijk toch besloten om Loxone te gaan inzetten in mijn huis. Dit biedt me iets minder vrijheid qua hardware, maar wel wat meer gemoedsrust wanneer er ooit problemen zijn, of als ik er niet meer zelf aan kan werken om welke reden dan ook. Ik woon er tenslotte niet alleen

Ik ben wel erg gecharmeerd van hoe de PFC200 werkt, en de mogelijkheden en vrijheden die het je biedt.

Zeker de Cloud Connectivity van de PFC200 is een meerwaarde vind ik. Daarmee kan je relatief snel een MQTT pub/sub mechanisme voor elkaar krijgen om je input en outputs te schakelen. Ik gebruikte hiervoor de Mosquito broker op de PFC zelf, maar dat kan even goed met Azure IoT hub, IBM BlueMix of andere providers gekoppeld worden zonder aanpassingen in je code.
Om de koppeling te maken heb ik e!Cockpit gebruikt met de WagoAppCloud library (FbPublishMQTT en FbSubscribeMQTT). Dat gecombineerd met de Homie MQTT convention zorgt ervoor dat dit ook discovered kan worden door bijvoorbeeld OpenHAB.

Indien iemand interesse heeft in de Wago PFC200 hardware, mag je me altijd een privé-bericht sturen of kijken bij V&A voor meer info (weet niet of ik hier een link mag toevoegen naar Vraag & Aanbod?).

[MichVw]

Na veel werk heb ik eindelijk m'n CoDeSys3 project afgewerkt en gedocumenteerd! het project maakt het mogelijk om makkelijk MQTT events te publishen en te subscriben op MQTT events. Met andere woorden: de core domotica logica word uitgevoerd in de PLC en MQTT events worden uitgestuurd als er bv een drukknop ingedrukt word of als er een output verandert van state. Aan de hand van MQTT subscriptions in de PLC is het dan weer mogelijk om outputs te gaan schakelen. Er zit veel logica in de software reeds verwerkt en ik ben van plan er nog toe te voegen in de toekomst, het hele project + documentatie kan je vinden op m'n git:

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

al bij al heeft het me ca. 2j gekost om alles uit te werken (niet fulltime natuurlijk ) dus als je je er kan in vinden om de git repository een star te geven kan ik dit zeker appreciëren

[Fraggar]

MichVw schreef op maandag 17 juni 2019 @ 15:32:
Bedoeling is om meer en meer functionaliteit toe te voegen in komende maanden en er hopelijk een kleine community in mee te krijgen van mensen die thuis allemaal zelfde approach gebruiken. Dat zou het leven van al die mensen gemakkelijker moeten maken

Ik heb inmiddels een PFC200 aangeschaft en wacht nog op de voeding, eindmodule en een module met digitale inputs. Daarna zou ik graag aan de slag gaan met jouw software.

Het is me nog niet duidelijk of ik hiervoor e-CockPit van Wago kan gebruiken, de 30-dagen-versie, of dat ik beter voor Codesys 3.5 kan gaan met de toevoeging van de Wago-targets.

Ook vraag ik me af of je een beknopte beschrijving kan geven van de stappen die ik moet nemen om een schakelaar uit te lezen middels een digitale ingang en dit signaal middels MQTT richting mijn eigen software kan sturen.

[MichVw]

Het is me nog niet duidelijk of ik hiervoor e-CockPit van Wago kan gebruiken, de 30-dagen-versie, of dat ik beter voor Codesys 3.5 kan gaan met de toevoeging van de Wago-targets.

Ik heb geen ervaring met e-CockPit maar dacht dat een licentie €1000+ kost.. met de free PFC200 targets van CodeSys kan je de PLC 2u laten draaien en dan moet je hem eens herstarten. Een licentie voor één toestel kost je €100, dan blijft de PLC draaien.. Ik zou opteren voor Codesys als je m'n software wilt gaan testen, gewoon omdat het daarin gebouwd is en dus mogelijkse externe problemen wegneemt.

Ook vraag ik me af of je een beknopte beschrijving kan geven van de stappen die ik moet nemen om een schakelaar uit te lezen middels een digitale ingang en dit signaal middels MQTT richting mijn eigen software kan sturen.

Een schakelaar of een drukknop? momenteel bestaat er enkel een functieblok voor een drukknop.
Het staat als eerste TODO op m'n lijstje om één toe te voegen voor een schakelaar maar daar heb ik de tijd nog niet voor gevonden.

[Fraggar]

MichVw schreef op zondag 23 juni 2019 @ 16:55:
De documentatie is afgewerkt en zit nu in de masterbranch. link is dus verandert
https://github.com/Michie.../Getting_started_guide.md

Inmiddels heb ik mijn PFC200 binnen, inclusief voeding, eindmodule en een 750-1405-module. Qua firmware heb ik versie 11 erop gezet vanuit deze post: Patrick_v_L in "Domotica met plc's"

Ik heb alle stappen doorlopen van de getting started guide, goed in elkaar gezet, waarvoor dank @MichVw!
Het device moest ik nog wel even updaten omdat het een vorige versie van CoDeSys betrof, maar ook dat is gelukt. Bij de laatste stap zou je nog als tip erbij kunnen zetten dat de fysieke knop op de PLC op "run" moet staan, dat had ik even niet door. En een kleinigheidje: de linkjes naar de "dedicated docs" werken momenteel niet.

Nu de software loopt heb ik een impulsdrukker op de eerste digitale ingang aangesloten en op de knop gedrukt. Ik heb zelf een MQTT-broker draaien en deze ingesteld op de PLC. Mijn client heb ik gesubscribed naar:

code:

WAGO-PFC200/Out/DigitalInputs/Pushbuttons/FB_DI_PB_001

Helaas zie ik niets voorbij komen als ik op een knop druk. Op de PLC zelf zie ik de status-LED wel even oplichten. Op de PLC branden de SYS- en RUN-LEDs groen, en gaat na een reboot de IO-LED even groen branden en dan uit. Verder knippert de NET-LED onregelmatig rood.

Heb ik het juiste MQTT-topic te pakken? Hoe kan ik dit verder het beste debuggen?

Edit: Ik had enkele IO-modules in het project laten staan die ik zelf niet bezit, blijkbaar wordt dat niet geaccepteerd, ook al zag ik verder geen errors. Na het opschonen van het project werkt het nu prima!

[ Voor 20% gewijzigd door Fraggar op 15-07-2019 17:11 ]

[Fraggar]

MichVw schreef op dinsdag 16 juli 2019 @ 14:23:
Bedankt @Fraggar voor je feedback! ik ga m'n docs updaten met de puntjes waar je (kleine) problemen ondervonden hebt. Uit interesse: hoe ver geraak je met de functionaliteit die momenteel in het project zit? Het staat op m'n lijstje om rolluiken toe te voegen maar had graag eens rondgehoord of er nog andere zaken zijn.

@MichVw Ik heb nog een aardige verlanglijst Ik ben van plan de PLC een groot deel van de sensoren in huis te laten afhandelen en via MQTT te versturen naar de domoticaserver. Ik volg grotendeels de aanpak van Femme.

- Ik heb de Panasonic AMN31112J op het oog als bewegingssensor. Die wordt dan op de PLC aangesloten middels de 753-434 en 750-612. Kan ik hiervoor de bestaande code uit jouw project gebruiken om de beweging door te geven?

- Daarna wil ik een radar module gaan testen, bijvoorbeeld de B+B HYG RAD-MOD die Femme aanraadt. Deze sluit ik dan middels de optokoppelaar 859-796 en eindplaat aan op de PLC. Hiervoor geldt dezelfde vraag als voor de bewegingsmelder.

- Ook wil ik aan de slag met magneetsensoren om te bepalen of ramen en deuren open of dicht zijn. Kan iemand me uitleggen hoe die concreet op de PLC zijn aan te sluiten? En ook hiervoor geldt de vraag of ik de software-kant met jouw software kan tackelen.

- In de huidige versie viel het me op dat je als MQTT-topic kiest voor een prefix en een specifieke input als suffix. Hierdoor moet je aan de client-zijde voor iedere input opnieuw op een topic subscriben. Dit zou ik persoonlijk liever algemener zien, bijvoorbeeld één topic voor alle impulsdrukkers. Aan de client-zijde op de domotica-server hoef je dan alleen op dat topic te subscriben en kun je de logica daar makkelijk verder regelen. Je zou middels json in de payload aan kunnen geven om welke input het gaat en wat de boodschap is. Hoe heb je dit in je eigen situatie geregeld?

[MichVw]

@Fraggar

- Panasonic AMN31112J op het oog als bewegingssensor.
- Daarna wil ik een radar module gaan testen, bijvoorbeeld de B+B HYG RAD-MOD die Femme aanraadt.
- Ook wil ik aan de slag met magneetsensoren om te bepalen of ramen en deuren open of dicht zijn.

=> deze drie lijken me allemaal sensoren die twee states hebben namelijk '0/off/low/closed/false' of '1/on/high/open/true' dus normaal gezien zou dat moeten lukken met de binary sensor input FB: https://github.com/Michie...NPUT_BINARYSENSOR_MQTT.md

de MQTT topic is inderdaad een concatinatie van het ingestelde prefix en de FB naam. Als je alle events wilt ontvangen voor alle sensoren kan je gewoon gebruik maken MQTT wildcards: 'WAGO-PFC200/Out/DigitalInputs/BinarySensors/#' bijvoorbeeld. Het MQTT protocol is echt gemaakt om zo te gaan toepassen zoals het nu in de PLC logica zit. Welke domotica software gebruik je precies? Bij OpenHAB en HomeAssistant zou het alvast geen probleem mogen geven met Domoticz heb ik geen ervaring maar aangezien het een vrij populair platform is zou het me verwonderen moest dit een probleem geven.

Mijn eigen situatie = Home Assistant, de configuratie van elke FB in Home Assistant word telkens meegeeven in de docs ook. Los van het feit dat ik HA gebruik zou de logica normaal gezien in iedere domotica platform integreerbaar moeten zijn.

[Fraggar]

MichVw schreef op woensdag 17 juli 2019 @ 07:41:
=> deze drie lijken me allemaal sensoren die twee states hebben namelijk '0/off/low/closed/false' of '1/on/high/open/true' dus normaal gezien zou dat moeten lukken met de binary sensor input FB

Top, dit ga ik proberen!

MichVw schreef op woensdag 17 juli 2019 @ 07:41:
de MQTT topic is inderdaad een concatinatie van het ingestelde prefix en de FB naam. Als je alle events wilt ontvangen voor alle sensoren kan je gewoon gebruik maken MQTT wildcards: 'WAGO-PFC200/Out/DigitalInputs/BinarySensors/#' bijvoorbeeld. Het MQTT protocol is echt gemaakt om zo te gaan toepassen zoals het nu in de PLC logica zit. Welke domotica software gebruik je precies?

Ik gebruik domoticasoftware die ik zelf heb ontwikkeld, maar deed vooralsnog niets met MQTT. Bedankt voor het verhelderen!

[MichVw]

Fraggar schreef op woensdag 17 juli 2019 @ 11:04:
[...]


Top, dit ga ik proberen!


[...]


Ik gebruik domoticasoftware die ik zelf heb ontwikkeld, maar deed vooralsnog niets met MQTT. Bedankt voor het verhelderen!

zelf ontwikkelde domoticasoftware gek! waarom ben je die richting uit gegaan?
Om de states van je items goed te krijgen in je domoticasoftware: het zit hem in de kleine dingen, zoals de MQTT retain flag. Een aanrader zou zijn om een te kijken hoe Home Assistant er mee omgaat in hun items:
- MQTT Binary switch: https://www.home-assistant.io/components/binary_sensor.mqtt/
- MQTT light: https://www.home-assistant.io/components/light.mqtt/
- MQTT sensor: https://www.home-assistant.io/components/sensor.mqtt/

in m'n PLC soft gebruik ik volgende guidelines als ik iets nieuw ontwikkel:
input (=sensor): indien het gaat om events => publish zonder retain, indien het gaat om state => publish met retain.
output (=actuator), geen retain flag maar wel een publish van de state op startup van de PLC

Verder heeft Home Assistant ook de optie om MQTT birth and last will toe te voegen aan items waardoor je items 'unavailable' worden als je device niet meer online is. Zit ook al in de PLC logica geimplementeerd

[MichVw]

@Kanze als je je erin kan vinden om een wago pfc100 of pfc200 aan te schaffen zou ik dit aanraden: https://github.com/Michie...e/HomeAutomation.CoDeSys3

Het is een referentie architectuur met MQTT om events uit te sturen vanuit de PLC. Aan de hand van subscripties kan je dan weer acties laten uitvoeren in de plc (bv schakelen outputs).

Ik ben er een dikke 2j mee bezig geweest om het op punt te krijgen. Een sterretje waardeer ik dan ook zeker 😉

[arjan_1980]

Ik ben het helemaal met je eens wat je aangeeft op je gifthub page, daarom heb ik ook voor een Wago plc gekozen voor de besturing van de verwarmings installatie, ik had gerust een andere weg kunnen bewandelen doormiddel van software draaien op mijn server.

Bij mij draait de wage plc zoals aangegeven alleen de verwarmings installatie, praat hierbij over een warmtepomp, warmtepomp boiler met panelen en een pelletketel, dit alles moet netjes gestuurd worden afhankelijk van de warmtevraag en behoefte. Tevens kan de warmtepomp koelen.

Ik gebruik voor de commandos naar en van de PLC gewoon de KNX library en communicatie module.

Reden dat de temperatuur waardes de KNX bus op moeten is dat ik een Divus KNX server gebruik voor de visualisatie, zodat alles grafisch in een omgeving blijft. Grens waarde aanpassingen kunnen ook van hieruit gedaan worden.

De kleine kast waar de loxone miniserver in zit gaat deze week van de muur en er komt een twee deurs kast voor in de plaats zodat alles netjes de ruimte heeft.

MichVw schreef op dinsdag 30 juli 2019 @ 17:34:
@Kanze als je je erin kan vinden om een wago pfc100 of pfc200 aan te schaffen zou ik dit aanraden: https://github.com/Michie...e/HomeAutomation.CoDeSys3

Het is een referentie architectuur met MQTT om events uit te sturen vanuit de PLC. Aan de hand van subscripties kan je dan weer acties laten uitvoeren in de plc (bv schakelen outputs).

Ik ben er een dikke 2j mee bezig geweest om het op punt te krijgen. Een sterretje waardeer ik dan ook zeker 😉

[ Voor 11% gewijzigd door arjan_1980 op 31-07-2019 07:44 ]

[UglyDinosaur]

Kanze schreef op zondag 11 augustus 2019 @ 01:19:
Reeds veel bijgeleerd uit dit topic waarvoor dank. Na veel lezen ben ik uitgekomen op de reeds beproefde combinatie van PFC200 met een netwerk van 1-Wire sensors en DMX voor sturing van LED verlichting.

Ikzelf ben ook bezig met mijn domotica te vernieuwen hier en heb gebruik gemaakt van de DS18B20 one-wire temperatuursensoren. Ik heb naakte sensoren gekocht en zelf de nodige kabels hier aan vast gemaakt en in een klein metalen busje gestoken en vastgezet met "Thermal glue". Dan een gaatje van 6mm geboord in de kader van een NIKO stopcontact en daarin vastgezet met een lijmpistool.

Voor de communicatie met de PFC200 met codesys kan je modules kopen, maar ik ben zelf gaan zoeken naar een andere oplossing omdat ik die te duur vond. Ik heb het ondertussen perfect werken gekregen met een arduino MEGA (arduino UNO heeft te weinig geheugen) die de sensoren uit leest en de data via MODBUS TCP doorstuurt naar de PLC. Heb ook nog een schermpje aangesloten op de arduino waarop de temperaturen te zien zijn en in de code ook dadelijk MQTT mogelijkheden ingebouwd.

Veel werk maar lekker goedkoop

[Fraggar]

In mijn huidige Z-Wave-netwerk heb ik een aantal "slimme"-stekkers opgenomen om stroommetingen door te geven. Op basis van het realtime-verbruik weet ik zo of de koelkast staat te koelen, of dat de koelkastdeur open is, of de afzuigkap aan staat, of de CV aan het verwarmen is, etc. etc. Prima manier dus om "domme" apparatuur toch enigszins connected te maken.

Hoe kan ik het realtime-verbruik van apparaten meten met behulp van een Wago PFC200? Welke modules heb ik nodig en zijn er voorbeelden beschikbaar hoe dit in CoDeSys via MQTT netjes kan worden gepublished?

[MewBie]

Fraggar schreef op vrijdag 6 september 2019 @ 11:36:
In mijn huidige Z-Wave-netwerk heb ik een aantal "slimme"-stekkers opgenomen om stroommetingen door te geven. Op basis van het realtime-verbruik weet ik zo of de koelkast staat te koelen, of dat de koelkastdeur open is, of de afzuigkap aan staat, of de CV aan het verwarmen is, etc. etc. Prima manier dus om "domme" apparatuur toch enigszins connected te maken.

Hoe kan ik het realtime-verbruik van apparaten meten met behulp van een Wago PFC200? Welke modules heb ik nodig en zijn er voorbeelden beschikbaar hoe dit in CoDeSys via MQTT netjes kan worden gepublished?

Wago heeft zo te zien geen Z-Wave modules, je zult dus iets moeten zoeken dat Z-Wave omzet in iets waar wel Wago modules voor zijn, of wat al op de PFC200 zit. Bijvoorbeeld RS-232, RS-485 of iets gebaseerd op ethernet.

[UglyDinosaur]

MewBie schreef op vrijdag 6 september 2019 @ 13:45:
[...]

Wago heeft zo te zien geen Z-Wave modules, je zult dus iets moeten zoeken dat Z-Wave omzet in iets waar wel Wago modules voor zijn, of wat al op de PFC200 zit. Bijvoorbeeld RS-232, RS-485 of iets gebaseerd op ethernet.

Heb je de verbruiken perse in je PLC nodig? Kan je met Node-Red niets doen? Ik ken niets van Z-wave maar mogelijk kan je de meters in node-red toevoegen en dan kan je voa MQTT er mee doen wat je wilt. Desnoods ook naar de PLC doorsturen en er daar mee doen wat je van plan bent...

[MichVw]

Ik zou ook voor de eastron modules gaan die je zo in je kast kan hangen. M'n initieel idee was om de modbus RTU om te zetten naar modbus TCP aan de hand van één van deze:
https://www.aliexpress.co...1602_3,searchweb201603_60

De reden daarvoor is vooral omdat ik niet meteen documentatie vond of forum posts om de functionaliteit te laten draaien op m'n PFC200 en daar de conversie te doen naar MQTT.

@tinus5 , als ik het goed heb dit werkend gekregen om uit te lezen via je PLC? heb je eventueel wat source code om andere personen op gang te zetten?

Indien je interesse hebt, maak gerust hier een issue aan ermee: https://github.com/Michie...e/HomeAutomation.CoDeSys3. Dan kijk ik om er een open source function block van te maken die iedereen kan gebruiken..

[UglyDinosaur]

MichVw schreef op zondag 8 september 2019 @ 19:22:
Ik zou ook voor de eastron modules gaan die je zo in je kast kan hangen. M'n initieel idee was om de modbus RTU om te zetten naar modbus TCP aan de hand van één van deze:
https://www.aliexpress.co...1602_3,searchweb201603_60

De reden daarvoor is vooral omdat ik niet meteen documentatie vond of forum posts om de functionaliteit te laten draaien op m'n PFC200 en daar de conversie te doen naar MQTT.

Ik heb net dezelfde opstelling en heb het aan de praat gekregen zoals jij het wil hebben. De eastron via Modbus RTU uitlezen in de PLC en dan via MQTT stuur ik de gegevens elke seconde door naar Node-Red (op ms raspberry) die het dan verder stuurt naar Influxdb en grafana.

Vergde wel wat opzoekwerk maar uiteindelijk is het gelukt. Werkt voorlopig perfect.

[MichVw]

benbam schreef op maandag 9 september 2019 @ 09:43:
[...]


Ik heb net dezelfde opstelling en heb het aan de praat gekregen zoals jij het wil hebben. De eastron via Modbus RTU uitlezen in de PLC en dan via MQTT stuur ik de gegevens elke seconde door naar Node-Red (op ms raspberry) die het dan verder stuurt naar Influxdb en grafana.

Vergde wel wat opzoekwerk maar uiteindelijk is het gelukt. Werkt voorlopig perfect.

Top! welke PLC/CodeSys runtime gebruik je? Sta je er voor open om de implementatie te delen?
Stuur me anders gerust een privaat berichtje of open hier een issue/feature request met het project in bijlage:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Bedoeling van m'n git repository is om dergelijke terugkerende functionaliteit in een algemene function block te gieten en die open source te maken. Met bijhorende uitgebreide documentatie.. Het is te gek dat we hier allemaal opnieuw terug het warm water zitten uit te vinden . Als we al onze ervaring wat samengieten besparen we elkaar tijd. Als we dan nog eens zelfde logica implementeren zijn we met meer die zelfde logica runnen en is er dus ook meer zekerheid dat alles werkt zoals het hoort.. teamwork makes dreamwork zeggen ze dan

PS: geef de repo gerust een star om het idee te steunen, er is heel wat werk in gekropen!

[Antonius]

AUijtdehaag schreef op vrijdag 6 september 2019 @ 15:57:
Kan zo een plc geen modbus rtu of tcp lezen?
Eastron kWh meters (zoek op ali) met modbus of finders met MBus en omzetter naar modbus tcp eventueel.

Ja dat kan wel. De PFC200 van Wago heeft een RS485 aansluiting aan boord waar je modbus rtu mee kunt communiceren, daar is dus niet altijd nog een extra 750-652 of 750-653 voor nodig. Of als je kWh meter modbus over tcp doet dan kan het gewoon over de ethernet aansluiting van de controller. Kan eventueel ook weer over MQTT doorsturen naar wat anders. Node red en Grafana las ik net, op een Raspbery PI. Dat heb ik ook al prima werkend gezien.

[MichVw]

Femme schreef op dinsdag 17 september 2019 @ 11:11:

Hoe ben je dan van plan logging te gaan doen? Via een omweg naar InfluxDB op single board computer?

éénmaal ik alle data heb uitgelezen via rs485 in m'n PLC ga ik die gewoon periodiek laten doorsturen via MQTT (een Wago PFC kan probleemloos QoS 2 dus is betrouwbaar). Vanaf daar heb je zelf de keuze om ermee te doen wat je wilt. Van mij zal het naar Home Assistant gaan waar er dan inderdaad een InfluxDB achter zit. SBC is een optie maar ik denk eraan om iets krachtiger te gebruiken.

Femme schreef op dinsdag 17 september 2019 @ 11:11:

Ik gebruik zelf de 1-wire interface van Symcon in combinatie met IP-Symcon

Interessant, op de Symcon site vind ik er twee terug: For connection to a PC, a USB adapter (DS9490R) or serial interface (DS9097U-S09) are available. Welke is het precies?

Bedankt voor je verdere tips voor het 1-wire netwerk, die zullen zeker van pas komen

[Femme]

MichVw schreef op dinsdag 17 september 2019 @ 11:54:
[...]


éénmaal ik alle data heb uitgelezen via rs485 in m'n PLC ga ik die gewoon periodiek laten doorsturen via MQTT (een Wago PFC kan probleemloos QoS 2 dus is betrouwbaar). Vanaf daar heb je zelf de keuze om ermee te doen wat je wilt. Van mij zal het naar Home Assistant gaan waar er dan inderdaad een InfluxDB achter zit. SBC is een optie maar ik denk eraan om iets krachtiger te gebruiken.

Ik heb zelf afgelopen zomer mijn meterkast een upgrade gegeven (in verband met de komst van 24 kWp aan PV-panelen) en daarbij alle groepen meetbaar gemaakt met behulp van Eastron SDM630MCT-2L energiemeters. Dat is een variant die twee 3-fase groepen meet met behulp van externe current transformers. Die CT's heb ik met behulp van een zelf geprint bracket geplaatst tussen de klemmenstrook waar de drie fases en nul op worden verdeeld vanaf de hoofdschakelaar naar de aardlekautomaten.



Hier waren ze half verwerkt in de meterkast:



Ik heb een module gemaakt om Eastron-meters te integeren in IP-Symcon. De module maakt automatisch de benodigde variabelen aan (een stuk of 50 bij een 3-fase meter), voert modbus requests waarbij ik prioriteit kan geven aan bepaalde metrics zodat die vaker worden uitgelezen. Er zit ook nog een scheduler achter die prioriteit kan geven aan bepaalde meters op dezelfde bus zodat die relatief vaker worden uitgelezen. Op die manier kan ik met 14 3-fase meters op één bus bijna elke seconde de stroomsterkte en het vermogen uitlezen van de meter op de hoofdaansluiting terwijl alle andere meters ook nog regelmatig worden uitgelezen.

Dat zou snel genoeg moeten zijn om later nog wat slimme loadbalancing te kunnen doen op een laadpaal .

Ik lag alles naar Symcon die een eigen data store heeft. Van daaruit gaat het voor visualisatie direct naar Grafana om grafiekjes zoals de onderstaande te maken. Hiervoor heb ik een simple Json datasource voor Grafana geïmplementeerd in een module voor IP-Symcon. Het voordeel van deze oplossing voor mij is dat ik maar van twee services afhankelijk ben (Symcon en Grafana, die op hetzelfde machientje draaien).



Wat betreft je wens om iets krachtigers dan een single board computer te gebruiken: er zijn tegenwoordig echt leuke bordjes met goede performance en veel mogelijkheden. Zo heb ik nu thuis een Khadas VIM3 liggen die net zo compact is als een RPi, maar wel een hexacore heeft (4x A73 op 2,2GHz en 2x A53 op 1,8GHz) met 4GB RAM, 32GB eMMC geheugen en een m.2-slot voor een ssd. Dus snel, zuinig en betrouwbare opslag.

[Heire]

Ik ben momenteel in bezit van een PFC100 en bezig in ecockpit, maar ook hier zie ik nu achteraf of mijn keuze wel goed was. Ik heb een 750-8102 aangekocht met een assortiment modules in de gedachte om achteraf de software te bekijken.
Nu merk ik op dat op zich ecockpit visueel wel goed werkt en de sturing met de PLC goed gaat, maar alleen in evaluatie werkt. Dus zit ik nu met een probleem wat erna.
Gezien ik hier opmerkingen lees van de nadelen om geen ecockpit te hebben, ben ik nu aan het twijfelen of ik nu codesys moet nemen of toch ecockpit.

Op zich ga ik mijn huis voornamelijk aansturen met de basis functionaliteiten en is mijn idee om de andere zaken via HA te doen (wanneer ik tijd heb). Nu gezien ik wel 1-wire en paar andere zaken via mijn PLC wil integreren en op termijn te combineren met MQTT is de vraag welke software is passende hierbij.
Toch Codesys voor 100euro of een starterkit van 900 euro om toch maar de licentie(ecockpit) te hebben.
Ik zie buiten de licentie (ecockpit) niet echt een voordeel om zoveel geld neer te tellen voor een PLC dat ik niet kan/ga gebruiken.

Wat gebruiken jullie voornamelijk of wat zou je aanraden?

[MichVw]

[b]Heire in "Domotica met plc's"
Op zich ga ik mijn huis voornamelijk aansturen met de basis functionaliteiten en is mijn idee om de andere zaken via HA te doen (wanneer ik tijd heb). Nu gezien ik wel 1-wire en paar andere zaken via mijn PLC wil integreren en op termijn te combineren met MQTT is de vraag welke software is passende hierbij.
Toch Codesys voor 100euro of een starterkit van 900 euro om toch maar de licentie(ecockpit) te hebben.
Ik zie buiten de licentie (ecockpit) niet echt een voordeel om zoveel geld neer te tellen voor een PLC dat ik niet kan/ga gebruiken.

Wat gebruiken jullie voornamelijk of wat zou je aanraden?

Uiteindelijk moet je long term gaan kijken, je kan inderdaad rond de e!cockpit trail periode rondwerken maar je kan niet 100% zeker zijn dat dat zo ook blijft in de toekomst.. Daarom alleen al zou ik voor CodeSys gaan, het hele doel van domotica via PLC's is net dat alles zeer betrouwbaar is en toekomstgericht.

Wat versta je precies onder basis functionaliteiten? Ik heb een project ontwikkeld waar alle basis functionaliteiten uitgevoerd worden in de PLC en er events worden doorgestuurd via MQTT om te integreren in HA, je kan ook commando's sturen via MQTT om bv outputs te gaan schakelen (allemaal QoS 2). Je kan alles hier terugvinden:
https://github.com/Michie...e/HomeAutomation.CoDeSys3
Er zijn al enkele mensen hier die er gebruik van maken Ik voeg nog RS485 support toe in de toekomst voor energiemeters en ook een FB voor rolluiken.

[Fraggar]

MichVw schreef op donderdag 26 september 2019 @ 07:59:
Er zijn al enkele mensen hier die er gebruik van maken Ik voeg nog RS485 support toe in de toekomst voor energiemeters en ook een FB voor rolluiken.

Ik volg je ontwikkelingen met interesse. Heb je ook een oplossing in gedachten om met de PLC 1-wire-sensoren uit te lezen en via MQTT door te sturen?

[MichVw]

Fraggar schreef op donderdag 26 september 2019 @ 11:36:
[...]

Ik volg je ontwikkelingen met interesse. Heb je ook een oplossing in gedachten om met de PLC 1-wire-sensoren uit te lezen en via MQTT door te sturen?

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!

[UglyDinosaur]

Fraggar schreef op donderdag 26 september 2019 @ 11:36:
[...]


Ik volg je ontwikkelingen met interesse. Heb je ook een oplossing in gedachten om met de PLC 1-wire-sensoren uit te lezen en via MQTT door te sturen?

Als je even terug gaat scrollen zal je zien dat ik hier een oplossing voor heb. Via arduino uitlezen en dan via modbus TCP doorsturen naar de PLC. Je kan de arduino ook gewoon rechtstreeks via MQTT de waardes laten doorsturen.

[-Paul-]

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

[MichVw]

-Paul- schreef op vrijdag 27 september 2019 @ 12:29:
Na een paar maanden met de PFC200 geklooid te hebben geef ik het op. Alle Wago spullen op V&A gezet en ik gebruik nu een Arduino met MQTT library die communiceert met Home Assistant. Wat een opluchting. Het is wat minder robuust, maar zoveel makkelijker en goedkoper.

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

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

[TailwindNL]

Wellicht interessant voor iemand --> DMX native vanuit Wago via een RS232/485 Wago module (750-652).

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

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

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

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

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

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

https://ibb.co/0ffN8sD

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

[-Paul-]

MichVw schreef op vrijdag 27 september 2019 @ 16:51:
[...]


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

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

Ja, dat ziet er veelbelovend uit voor MQTT. Mijn probleem was om DMX aan de praat te krijgen. Ik wilde alle basisfuncties in de PLC programmeren. Maar zowel via de 750-652 als via ArtNet niet gelukt.

[TailwindNL]

MichVw schreef op zaterdag 28 september 2019 @ 11:31:
[...]


Ik heb altijd interesse in projectfiles, waarschijnlijk zal je vanuit e!cockpit wel een export moeten nemen naar iets dat CoDeSys ook kan lezen..

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

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

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

[MichVw]

smaertens schreef op zaterdag 28 september 2019 @ 16:20:
Hallo,

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

Ik heb de allereerste lichten werkend gekregen.

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


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

Hartelijk dank!

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

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

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