Domotica met plc's

[MichVw]

Kanze schreef op dinsdag 26 april 2022 @ 01:14:
Ik zit met een vervelend probleem met m'n Eastron SDM630's. Zo heb ik er vier die allen uit een lot komen van begin 2020. Alle functies uitlezen lukt prima net als alle relevant holding registers schrijven via Modbus.

Maar het probleem is dat ik een foutcode krijg wanneer ik het holding register wil schrijven welke de totale energiemeting terug op nul zet. Ik weet dat mijn code correct is omdat ik ook enkele meters heb van een lot uit 2021 en die reageren wel correct op dat commando.

De oudere meters geven ook een modbus foutcode terug (05 - internal error). Ik vind er niets van op Google en berichten naar Eastron worden genegeerd. Zitten hier mensen die dit gedrag ook al gezien hebben?

Hieronder zie je een trace van pymodbus. Het uitgaande commando werkt prima maar de reply bevat foutcode 05. Zie lijncode 13 hieronder.

code:

2022-04-21 22:36:21,597 MainThread DEBUG transaction :139 Current transaction state - IDLE

2022-04-21 22:36:21,597 MainThread DEBUG transaction :144 Running transaction 1

2022-04-21 22:36:21,597 MainThread DEBUG transaction :273 SEND: 0x5 0x10 0x0 0xd8 0x0 0x2 0x4 0x3f 0x80 0x0 0x0 0xe7 0x99

2022-04-21 22:36:21,598 MainThread DEBUG sync :76 New Transaction state 'SENDING'

2022-04-21 22:36:21,598 MainThread DEBUG transaction :287 Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'

2022-04-21 22:36:21,624 MainThread DEBUG transaction :375 Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'

2022-04-21 22:36:21,624 MainThread DEBUG transaction :297 RECV: 0x5 0x90 0x1 0xcc 0x1

niet echt een antwoord op je vraag maar ik heb gemerkt dat ze wel eens een enorme uitschieter durven hebben ook qua data. bv van 5kWh plots naar 80kWh en dan terug naar 5kWh.

de laatste weken ben ik er in geslaagd om ze te integreren met m'n PLC ook;
https://github.com/Michie...EASTRON_SDM_POWER_MQTT.md

enkel lees ik enkel het active vermogen uit, het verbruik laat ik Home Assistant berekenen adhv Reimann sum integratie (manier waarop staat in docs vanonder)

[Kanze]

THM0 schreef op dinsdag 26 april 2022 @ 07:12:
[...]

Heb je wellicht de MID variant? Die kun je niet resetten.

Voor zover ik kan zien zijn alle SDM630 varianten MID-certified. Bovendien lukt het wel om mijn nieuwere SDM630 (lot van 2021) wel te resetten, maar de oudere meters (lot van 2020) niet.

Ik heb het gevoel dat er een hardware probleem is.

[THM0]

Kanze schreef op dinsdag 26 april 2022 @ 10:36:
[...]


Voor zover ik kan zien zijn alle SDM630 varianten MID-certified. Bovendien lukt het wel om mijn nieuwere SDM630 (lot van 2021) wel te resetten, maar de oudere meters (lot van 2020) niet.

Ik heb het gevoel dat er een hardware probleem is.

Volgens mij is er ook een non-MID versie. Maar als je inderdaad de MID versie hebt, dan is dat meteen de verklaring waarom de reset van totalen niet lukt: dat is een van de 'features' die bij de MID certificering hoort.

[Kanze]

THM0 schreef op dinsdag 26 april 2022 @ 10:40:
[...]

Volgens mij is er ook een non-MID versie. Maar als je inderdaad de MID versie hebt, dan is dat meteen de verklaring waarom de reset van totalen niet lukt: dat is een van de 'features' die bij de MID certificering hoort.

Ben eens gaan kijken in de kast maar ik zie geen uitwendige kenmerken waaruit ik kan afleiden of het nu een MID versie is of niet. Kan dat ergens uitgelezen worden via modbus bijvoorbeeld?

[Step5]

Kanze schreef op dinsdag 26 april 2022 @ 11:29:
[...]


Ben eens gaan kijken in de kast maar ik zie geen uitwendige kenmerken waaruit ik kan afleiden of het nu een MID versie is of niet. Kan dat ergens uitgelezen worden via modbus bijvoorbeeld?

Maar waarom wil je uberhaupt die tellers resetten?

[MichVw]

ik heb wat hardware vragen waar ik hoop dat jullie me eventueel kunnen hij helpen;

1. welke leddrivers gebruiken jullie? ik ben op zoek naar iets din mounted waar ik gewoon een aan/uit signaal kan naar sturen maar dat ook een 'fade' ondersteund bij het aan en uit schakelen

2. ik had graag gebruik gemaakt van bewegingsdedectoren maar dat ligt wat moeilijk door een aantal viervoeters in huis. Zijn er hier mensen die daar een oplossing voor gevonden hebben?

3. laatste (en belangrijkste eigenlijk); ik zou m'n radiatoren willen aansturen via zoneventielen op een collector maar heb wat moeite om daar de juiste hardware voor te vinden zodat het allemaal mooi inéén past. Iemand ervaring mee?

[Kanze]

MichVw schreef op maandag 13 juni 2022 @ 09:47:
ik heb wat hardware vragen waar ik hoop dat jullie me eventueel kunnen hij helpen;

1. welke leddrivers gebruiken jullie? ik ben op zoek naar iets din mounted waar ik gewoon een aan/uit signaal kan naar sturen maar dat ook een 'fade' ondersteund bij het aan en uit schakelen

2. ik had graag gebruik gemaakt van bewegingsdedectoren maar dat ligt wat moeilijk door een aantal viervoeters in huis. Zijn er hier mensen die daar een oplossing voor gevonden hebben?

3. laatste (en belangrijkste eigenlijk); ik zou m'n radiatoren willen aansturen via zoneventielen op een collector maar heb wat moeite om daar de juiste hardware voor te vinden zodat het allemaal mooi inéén past. Iemand ervaring mee?

Als je over LED drivers spreekt die DIN mounted moeten zijn dan is het de bedoeling deze centraal in de kast te monteren? In dat geval zou ik gewoon klassieke DC voedingen gebruiken met een externe PWM dimmer.

Ik heb verschillen Meanwell NDR 480W (24V 20A) voedingen in gebruiken. Die nemen in een kast minder plaats in als een LRS bijvoorbeeld maar zijn wel bedoeld voor industriële kasten en hebben dan ook een hele grote diepgang. Bonus is dat je eenvoudig langs de onderkant een 120mm ventilator kan monteren voor koeling.

Dimmen zelf doen we met zelgemaakte dimmers en off the shelf PWM dimmers

[MichVw]

Kanze schreef op dinsdag 14 juni 2022 @ 12:34:
[...]


Als je over LED drivers spreekt die DIN mounted moeten zijn dan is het de bedoeling deze centraal in de kast te monteren? In dat geval zou ik gewoon klassieke DC voedingen gebruiken met een externe PWM dimmer.

Ik heb verschillen Meanwell NDR 480W (24V 20A) voedingen in gebruiken. Die nemen in een kast minder plaats in als een LRS bijvoorbeeld maar zijn wel bedoeld voor industriële kasten en hebben dan ook een hele grote diepgang. Bonus is dat je eenvoudig langs de onderkant een 120mm ventilator kan monteren voor koeling.

Dimmen zelf doen we met zelgemaakte dimmers en off the shelf PWM dimmers

Ik heb 2 Meanwell NDR 240W in m’n kast hangen. Inderdaad goed om wat plaats te besparen in de breedte. Lukt het om je PWM dimmers aan te sturen via PLC?

[MichVw]

Dit zijn trouwens mijn twee kasten:





De grote rechstaande is nog niet af, momenteel gebruik ik de PLC daar als testtoestel als ik zaken ontwikkel.

Overlaatst is het gelukt om 1-Wire data in de PLC binnen te trekken via een Esera Modbus gateway, functionaliteit zit in m’n project sinds deze week:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

[TLDNL]

Ik kan deze Dalcnet drivers aanraden.
https://www.dalcnet.com/en/MODBUS/15678-DLD1248-4CV-MODBUS

Je hebt ze in verschillende versies en grotes in Constant Current en Constant Voltage. Ook te sturen met 0-10V.

[Wafje]

TLDNL schreef op vrijdag 24 juni 2022 @ 14:51:
Ik kan deze Dalcnet drivers aanraden.
https://www.dalcnet.com/en/MODBUS/15678-DLD1248-4CV-MODBUS

Je hebt ze in verschillende versies en grotes in Constant Current en Constant Voltage. Ook te sturen met 0-10V.

Intressant, in welke pricerange bevinden deze zich?

[TLDNL]

Luxendi is de NL distribiteur. Prijzen op de website zijn bruto prijzen. Ik meen dat ze per 4 stuks nog extra staffelkorting geven.

https://www.luxendi.com/nl-nl/dalcnet-kopen/

[ Voor 18% gewijzigd door TLDNL op 25-06-2022 15:20 ]

[Kanze]

Waar kopen jullie je modules aan? Ik keek vandaag eens op Ebay naar enkele DO modules (750-530) en de prijzen lijken me redelijk hoog? Op z'n minst 60 euro voor een 8x DO kaart. Een gevolg van de inflatie misschien?

edit; Uiteindelijk toch geslaagd van 10x 750-530 op de kop te tikken in Polen voor 170 euro. Gelukkig hoef je je met industrieel materiaal weinig zorgen te maken over tweedehandsaankopen.

[ Voor 30% gewijzigd door Kanze op 05-07-2022 00:05 ]

[MichVw]

Kanze schreef op maandag 4 juli 2022 @ 23:39:
Waar kopen jullie je modules aan? Ik keek vandaag eens op Ebay naar enkele DO modules (750-530) en de prijzen lijken me redelijk hoog? Op z'n minst 60 euro voor een 8x DO kaart. Een gevolg van de inflatie misschien?

edit; Uiteindelijk toch geslaagd van 10x 750-530 op de kop te tikken in Polen voor 170 euro. Gelukkig hoef je je met industrieel materiaal weinig zorgen te maken over tweedehandsaankopen.

Waar in Polen? Ik was gisteren ook aan het rondkijken en ondervond die €60 ook!

[Giblet]

MichVw schreef op dinsdag 5 juli 2022 @ 07:24:
[...]


Waar in Polen? Ik was gisteren ook aan het rondkijken en ondervond die €60 ook!

Ik heb volgens mij nog 7 keer 750-530 liggen (oudere en nieuwere modellen, aan de ledjes te zien) en ook nog een 753-530 en een 750-1504 waar ik wel zonder kan. PM maar even als er behoefte is.

Overigens had ik zelf ook nog weleens geluk op ebay met bepaalde kaarten als je zoekt op de 753 serie ipv de 750. Die hebben dan wel 753-110 connector nodig die er niet altijd bij zit, maar die vallen qua prijs wel mee, zelfs nieuw dacht ik. Nadeel is dat die een iets kleinere draad diameter aan kunnen in verkelijking met de 750 serie...

[ Voor 7% gewijzigd door Giblet op 06-07-2022 14:32 ]

[gassiepaart]

Ik ben op zoek naar een Wago starterkit, bv deze, maar ik zie nergens een webshop die dit aanbiedt... Weten jullie nog manieren om aan een recente basis eenheid te komen zonder de hoofdprijs te betalen?

[KoBolD54]

gassiepaart schreef op maandag 11 juli 2022 @ 15:01:
Ik ben op zoek naar een Wago starterkit, bv deze, maar ik zie nergens een webshop die dit aanbiedt... Weten jullie nog manieren om aan een recente basis eenheid te komen zonder de hoofdprijs te betalen?

Als partner van Wago heb ik die van mij daar rechtstreeks besteld destijds. Ik weet niet of je bij hen ook rechtstreeks kan bestellen. Mocht het nou niet lukken stuur mij dan een DM, wellicht kan ik je helpen.

[gassiepaart]

KoBolD54 schreef op maandag 11 juli 2022 @ 15:11:
[...]

Als partner van Wago heb ik die van mij daar rechtstreeks besteld destijds. Ik weet niet of je bij hen ook rechtstreeks kan bestellen. Mocht het nou niet lukken stuur mij dan een DM, wellicht kan ik je helpen.

Ik heb me daar geregistreerd, maar als particulier vrees ik dat ik uiteindelijk niet door de screening kom... Sowieso lijkt het als particulier nogal lastig om nieuwe onderdelen te bestellen

[TLDNL]

Ik heb een paar van die starterskits besteld in februari. Levertijd is waarschijnlijk pas eind november. Ik denk dat het heel lastig is om de 750-8212 tegen redelijke prijzen op korte termijn te kunnen krijgen.
Soms heb je een gelukje op ebay of marktplaats.

[MichVw]

Ik heb er helaas al één maar Esera verkoopt tweedehands 1-Wire/Modbus gateways aan sterk verminderde prijs:
https://esera.de/11324-GB/1-wire-gateway-10-modbus-rtu
€80 ipv €250! (excl btw en verzendingskosten)

Ik gebruik er al even één die ik uitlees met m'n PLC, function block zit in project:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

[TLDNL]

Dank je wel voor de tip. Ik ga ze ook bestellen!

[Invisible_man]

Bij mij op het werk gebruiken wij veel Wago 750-8212's en we zijn alle mogelijke kanalen waar je alleen als bedrijf kan bestellen, inclusief Wago zelf, wel afgegaan en overal is het een kwestie van maanden wachten. We hebben ook naar andere typen in de PFC-200 reeks gezocht want op een gegeven moment heb je liever een duurdere variant dan geen, maar ook dat is overal uitgeput. Ook bepaalde io-modules zoals 4-20mA analoge ingangskaarten zijn moeilijk te krijgen.

En niet alleen bij Wago, ik heb vorige week een Siemens PLC binnengekregen die ik in September 2021 besteld heb. En dan niet eens één of andere obscure variant, maar gewoon één van hun meest gangbare types.

[TailwindNL]

MichVw schreef op dinsdag 14 juni 2022 @ 20:50:
Dit zijn trouwens mijn twee kasten:

[Afbeelding]

[Afbeelding]

De grote rechstaande is nog niet af, momenteel gebruik ik de PLC daar als testtoestel als ik zaken ontwikkel.

Overlaatst is het gelukt om 1-Wire data in de PLC binnen te trekken via een Esera Modbus gateway, functionaliteit zit in m’n project sinds deze week:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Dank voor de plaatjes. Het valt mij altijd op dat er zo ontzettend veel groep-schakelaars inzitten (of zijn het niet allemaal standaard groeps-schakelaars zoals in een reguliere non-domotica meterkast te vinden is? (ik doel op de schakelaars met zwarte en blauwe hendels op de foto's).

Is er ergens goede documentatie te vinden over de opbouw van deze kasten? (ik ben met name geïnteresseerd in de groepsindeling / calculatie)

[Femme]

Zo heb ik het vorig jaar aangepakt bij het verbouwen van onze schuur tot woon/werkruimte. De Wago-plc is hier niet in beeld (zit onderin de kast). Ik heb een kast op maat gemaakt in 19 inch formaat met aluminium bekleding aan de binnenkant.

Je ziet hier van boven naar beneden een rail met voedingen (12 en 24 VAC en 5, 12, 24 en 48 VDC) en de hoofdschakelaar, een rail met aardlekautomaten en daarboven rails met rijgklemmen, relais (en een DMX-dimmer) en in de top de installatieklemmen waar de 230V bedrading op is aangesloten.

Het DC-gebeuren voor onder andere led-verlichting, 1-wire en rijgklemmen voor de digitale inputs en outputs zit onderin en in de zijkant van de kast.

De AC-bedrading die verticaal loopt zit rechts in de kast, DC en communicatiekabel links. Van daar ook dat de relais rechts zijn uitgelijnd.

Er zit ook nog een CT-strip in die het energieverbruik van de groepen meet via een Anord Mardix Multi Circuit Monitor.

Achteraf gezien had ik grotere kabelgoten moeten gebruiken voor de bovenste goot voor de VD-draden. Neem je kabelgoten altijd groter dan je nodig denkt te hebben .

[ Voor 5% gewijzigd door Femme op 13-07-2022 15:28 ]

[MichVw]

TailwindNL schreef op woensdag 13 juli 2022 @ 13:59:
[...]


Dank voor de plaatjes. Het valt mij altijd op dat er zo ontzettend veel groep-schakelaars inzitten (of zijn het niet allemaal standaard groeps-schakelaars zoals in een reguliere non-domotica meterkast te vinden is? (ik doel op de schakelaars met zwarte en blauwe hendels op de foto's).

Is er ergens goede documentatie te vinden over de opbouw van deze kasten? (ik ben met name geïnteresseerd in de groepsindeling / calculatie)

je bedoeld automaten? ja in m'n grootste kast zitten er inderdaad een hoop, maar daar word ook afgetakt naar een paar bijgebouwen en zijn er ook nog voorzien voor laadpalen. Dat zijn de twee bovenste rijen in de onderste foto. De rest zijn automaten voor het huis, zijn er inderdaad een hoop maar die zijn rap gebruikt hoor.
naar indeling toe: alle natte ruimtes, vaatwasmachines, droogkast, wasmachine, etc steek je na de differentieel van 30mA. Al de rest ervoor, per automaat mag je 8 lichtpunten of 8 stopcontacten (doet er niet toe of het een stopcontact van 1,2 of 3 is). Beter een automaat teveel dan te weinig; het is altijd handig als er één toestel faalt dat er zo weinig mogelijk andere zaken ook afspringen omdat de automaat afspringt.

[MichVw]

om een voorbeeld te geven van een ééndraadschema:
300mA:

30mA:


ze staan natuurlijk samen op één plan maar was te groot voor een deftige screenshot.
Dit is nu uitgetekend met autocad omdat het de finale versie is maar handgetekend beginnen is een aanrader!

[TLDNL]

MichVw schreef op dinsdag 12 juli 2022 @ 15:56:
Ik heb er helaas al één maar Esera verkoopt tweedehands 1-Wire/Modbus gateways aan sterk verminderde prijs:
https://esera.de/11324-GB/1-wire-gateway-10-modbus-rtu
€80 ipv €250! (excl btw en verzendingskosten)

Ik gebruik er al even één die ik uitlees met m'n PLC, function block zit in project:
https://github.com/Michie...e/HomeAutomation.CoDeSys3

Michiel,

Gebruik jij daar ook een 1-wire termninator bij?

https://esera.de/en/Servi...-blocks/398/1-Wire-Term-1

Het 1-wire protocol schrijft toch geen terminatie voor?

[mikevaneerd]

Een ander mooi platform voor mensen die hiermee willen experimenteren is PLCNext van Phoenix. Het is een soort kruising tussen een raspberry Pi en een PLC. Hij beschikt over een Linux kernel waarin een real-time PLC applicatie draait. Beste van beide werelden dus!

Voordelen:
- Je kunt er docker containers op draaien, dus in theorie kun je HA ook draaien op je PLC;
- Gratis ontwikkel omgeving (PLCNext engineer maar je zou ook Eclips kunnen gebruiken);
- Mogelijkheid om ook met hogere programmeertalen zoals C++ de hardware uit te lezen/aan te sturen;
- Beschikt over een interne webserver voor visualisatie;
- Mogelijkheid om informatie tussen realtime gedeelte en linux omgeving te delen;
- In de app store zijn ook al genoeg librairies example projects te vinden die je op weg kunnen helpen. VB: Modbus TCP & RTU, AnalogTechnology, PLCNextBase.

Aantal handige links voor de geinteresseerde:
Starterskit
PLCNext
PLCNext forum
PLCNext app store
Artikel plcnext i.c.m. home assistant
Duidelijke Youtube tutorials

[TLDNL]

Het is zeker een interessant platform. Maar zo nieuw dat er nog weinig 2e hands op de markt is. Hoewel dat nu met alle merken zo is dat er weinig te krijgen is. Of je moet met Beckhoff PLC's die nog de KL klemmen ondersteunen aan de gang willen gaan.

[MichVw]

TLDNL schreef op donderdag 14 juli 2022 @ 13:00:
[...]


Michiel,

Gebruik jij daar ook een 1-wire termninator bij?

https://esera.de/en/Servi...-blocks/398/1-Wire-Term-1

Het 1-wire protocol schrijft toch geen terminatie voor?

Ik heb er -momenteel- geen maar mijn netwerk moet nog groeien.. Mogelijks koop ik er ook één aan als ik nog eens sensoren inkoop..

[Dippel]

Hier inmiddels ook de gebrauchte esera gateway besteld. Al een tijd op het oog, en met dit prijsverschil kon ik het niet links laten liggen. @MichVw dank voor de tip zodra hij binnen is zal ik de library een test geven.

[Wafje]

TLDNL schreef op donderdag 14 juli 2022 @ 14:15:
Het is zeker een interessant platform. Maar zo nieuw dat er nog weinig 2e hands op de markt is. Hoewel dat nu met alle merken zo is dat er weinig te krijgen is. Of je moet met Beckhoff PLC's die nog de KL klemmen ondersteunen aan de gang willen gaan.

Ik dacht dat de meeste beckhoff PLCs nog KL klemmen ondersteunen? Ik heb beckhoff zelf nog niet gecontacteerd hieromtrend, maar ik was van plan om mijn kast met KL klemmen uit te voeren.

Redenen:
* lager energieverbruik
* DALI ondersteuning

[Santford]

Wafje schreef op donderdag 14 juli 2022 @ 16:14:
[...]


Ik dacht dat de meeste beckhoff PLCs nog KL klemmen ondersteunen? Ik heb beckhoff zelf nog niet gecontacteerd hieromtrend, maar ik was van plan om mijn kast met KL klemmen uit te voeren.

Redenen:
* lager energieverbruik
* DALI ondersteuning

Zover ik kan zien ondersteunen de PLC's in de CX serie zowel E-bus als K-bus (en daarmee KL klemmen).
Anders biedt een EtherCAT bus coupler als de BK1120 een oplossing.

[Wafje]

mikevaneerd schreef op donderdag 14 juli 2022 @ 13:49:
Een ander mooi platform voor mensen die hiermee willen experimenteren is PLCNext van Phoenix. Het is een soort kruising tussen een raspberry Pi en een PLC. Hij beschikt over een Linux kernel waarin een real-time PLC applicatie draait. Beste van beide werelden dus!

Voordelen:
- Je kunt er docker containers op draaien, dus in theorie kun je HA ook draaien op je PLC;
- Gratis ontwikkel omgeving (PLCNext engineer maar je zou ook Eclips kunnen gebruiken);
- Mogelijkheid om ook met hogere programmeertalen zoals C++ de hardware uit te lezen/aan te sturen;
- Beschikt over een interne webserver voor visualisatie;
- Mogelijkheid om informatie tussen realtime gedeelte en linux omgeving te delen;
- In de app store zijn ook al genoeg librairies example projects te vinden die je op weg kunnen helpen. VB: Modbus TCP & RTU, AnalogTechnology, PLCNextBase.

Aantal handige links voor de geinteresseerde:
Starterskit
PLCNext
PLCNext forum
PLCNext app store
Artikel plcnext i.c.m. home assistant
Duidelijke Youtube tutorials

Ik had dit ook ooit besproken met een collega van me. Zeker interessant. Heb je er zelf ervaring mee?

[mikevaneerd]

Wafje schreef op donderdag 14 juli 2022 @ 16:49:
[...]


Ik had dit ook ooit besproken met een collega van me. Zeker interessant. Heb je er zelf ervaring mee?

Jazeker, ik heb de training gevolgd en ben momenteel met een eerste project bezig. Tot nu toe bevalt het erg goed. Het is vooral voor machine bouwers of stand alone installaties interessant naar mij mening. Voor een complete fabriek/proces automatisering kies ik op dit moment toch liever Siemens. Vooral omdat de interne webserver nog lang niet zover is als de concurrentie. Denk hierbij aan recepten, alarmviewer etc. Je zou het wel als softwarematige kroonsteen kunnen gebruiken voor externe applicaties.

[TLDNL]

Santford schreef op donderdag 14 juli 2022 @ 16:26:
[...]

Zover ik kan zien ondersteunen de PLC's in de CX serie zowel E-bus als K-bus (en daarmee KL klemmen).
Anders biedt een EtherCAT bus coupler als de BK1120 een oplossing.

Ik zie dat ik de zin veel negatiever geformuleerd had dan ik eigenlijk bedoelde.
Als je een CX PLC betaalbaar kan krijgen dan zijn de KL klemmen absoluut een goed alternatief. Zeker ook omdat de KL vaak een heel stuk goedkoper op de tweedehandsmarkt kan vinden.

[Santford]

TLDNL schreef op donderdag 14 juli 2022 @ 19:00:
[...]


Ik zie dat ik de zin veel negatiever geformuleerd had dan ik eigenlijk bedoelde.
Als je een CX PLC betaalbaar kan krijgen dan zijn de KL klemmen absoluut een goed alternatief. Zeker ook omdat de KL vaak een heel stuk goedkoper op de tweedehandsmarkt kan vinden.

Ik had het geenzins negatief opgevat, je hebt een goed punt. Van de KL klemmen worden tweedehands met regelmaat partijen aangeboden tegen een leuke prijs.
Het staat me bij dat een paar jaar geleden de CX7000 is uitgekomen voor kleine applicaties, met standaard ook al wat I/O aan boord. Ik heb alleen geen idee hoe het zit met de beschikbaarheid en de prijs ervan.

[TLDNL]

Dat weet ik ook niet. Ik zie wel dat de Beckhoff PLC's met Twincat 2 nog enigzins betaalbaar zijn. De Twincat 3 varianten zijn niet te betalen.

[MichVw]

Dit is iets voor V&A, niet voor het forum

[ Voor 89% gewijzigd door Outerspace op 09-08-2022 00:10 ]

[DavidZH]

mikevaneerd schreef op donderdag 14 juli 2022 @ 13:49:
Een ander mooi platform voor mensen die hiermee willen experimenteren is PLCNext van Phoenix.

...

Late to the party... Maar wij hebben een starterkit op het werk staan van PLCNext. En toen er een vertegenwoordiger van Phoenix langskwam bood hij nog net niet €5k om dat ding over te nemen. Ze zijn erg gewild geloof ik. Maar ja, welke serieuze PLC op dit moment niet...

Mear dit is zeker wel een richting om in de gaten te gaan houden voor eventuele domotica applicaties. Het ding is ook mooi compact.

[meijer3]

Wat een fijne (maar een lange) topic. Veel ingelezen en volg het met plezier. Zal wel een andere keer mijn hele idee posten (opensource passiv haus). Maar voor nu even over Wago PLCs

Jaar geleden zag ik Fenne's post over PLCs toen dacht ik. Nah dat is ouderwets, en na marktonderzoek is er eigenlijk niets beters wat betaalbaar + bedraad is. Ik dacht ergens nog iets zelf te bouwen met EPS32 en powerlinecommunications, maar nee. De hele Wago's bevalt me wel. Tweedehands is veel duurzamer dan een hoop extra nieuwe (veel lijdelijkere) ESPs. (Al zijn die natuurlijk nog goed bruikbaar voor andere projectjes).

Vraag 1: Ik zie, na een snel onderzoekje, dat 8x 16x modules niet perse goedkoper zijn per port. Bij ruimte zou ik dus voor 4x di/do kiezen. Zijn er andere nadelen dan de breedte (energie gebruik?). Bekabeling lijkt me juist weer makkelijker.



Vraag 2: 24v gaat naar de sensor. Alle 24v op het zelfde blok. DI komt terug. Dit loopt via een rijgklem. De mapping kan dan analoog (omprikken) of digitaal via e!cockpit. Wat heeft de voorkeur?

Vraag 3: Ergens las ik dat je beter 24V voor de controler apart kan houden van de DI/DO, want dan branden ze niet allebei op iig. En ook nog redundant. Hebben jullie allemaal 2x 2x 24volt ?

Opmerking. @MichVw hele fijne repo. Goed bezig.

[Rob Z]

@meijer3 Uiteindelijk kom je op een prijs per IO punt uit.
Bedrading hoeft niet perse op een rijgklem maar kan ook rechtstreeks naar bijvoorbeeld een IO kaart of relais.
Voeding kun je daarvoor dan verdelen met bijvoorbeeld een potentiaalverdeelklem.

De CPU apart voeden (zekeringen of installatieautomaten hier) van de IO is een goede gewoonte omdat er altijd wel wat misgaat in het veld.

Redundante voeding heb ik niet, maar bedrijfsmatig wel vaak toegepast.

Wat ik wel heb is een mogelijkheid om de belangrijkste relais (badkamer, WC etc.) rechstreeks te bekrachtigen via een schakelaar en wat diodeklemmen. Dan brandt er nog wat licht als de PLC uitvalt, maar dat is in ruim 3 jaar nog niet voorgekomen. Al het (nieuwe) spul is nog heel.

[TLDNL]

@meijer3
De meervoudige units worden vaak gebruikt voor ruimte besparing.

Mocht je persee een PFC200 willen, ga dan voor eentje uit de 2e generatie zodat je ook docker kan draaien.
Indien je dat niet wenst zou je ook voor een goedkoperen 750-8102 (PFC100) kunnen gaan.

Mocht je de Wago PLC's puur als IO willen dan zou je ook voor een Modbus/TCP kopstation kunnen gaan in combinatie met bijvoorbeeld node-red of python.

[MichVw]

@meijer3,
inderdaad draait het allemaal om de prijs per IO punt, als ik plaats heb in de kast gebruikt ik 4x klemmen, als plaats nauwer is ga ik naar 8x klemmen.

ik heb een redundante 24V voeding in de woning, of dat effectief nodig was zullen we zien in de toekomst veronderstel ik..

hou er rekening mee dat als je voor de PFC100 gaat dat je geen onboard RS485 hebt, daar zijn leuke toepassingen voor.

[TLDNL]

De 750-8102 heeft wel RS232/485 onboard. De andere modellen niet.
Ik geloof dat deze versie ook een iets snellere chip en meer geheugen heeft.

[meijer3]

Met deze topic in gedachten, PLCs als core. Kan ik ook niet los laten hoe makkelijk esp/esphome is. Daarom was ik een repo begonnen met het ontwerp van een mini-PLC-controller.

Het idee is dat we de essentials via PLC doen. En non-essentials als extra, dus via esp's, wired terug naar de meterkast kunnen communiceren. Hiervoor het ik een concept geschetst op github.



https://github.com/meijer3/socket_plc (hier staat nog veel meer in de readme.md )

Er zijn nog een paar punten die voor mij onzeker zijn.
1. Hoe ik van 24v zuinig naar 3.3v kan (ben niet zo goed met pcb's)
2. Rx/Tx via esp door een ethernetkabel naar de meterkast kan communiceren. Modbus misschien?
3. Watt verbruik meten met de esp van de 230v.

Aanvullingen suggesties zijn welkom (eigenlijk hoop ik dat we de koppen bij elkaar kunnen steken).

En prototype twee is dan een ethernet kabel naar een raam, en dan de blinds regelen + 2 lokale knoppen + mogelijkheid voor een esp lokaal.

ps. idee is om kompleet wired te zijn

[bartw2604]

meijer3 schreef op vrijdag 26 augustus 2022 @ 10:44:
Met deze topic in gedachten, PLCs als core. Kan ik ook niet los laten hoe makkelijk esp/esphome is. Daarom was ik een repo begonnen met het ontwerp van een mini-PLC-controller.

Het idee is dat we de essentials via PLC doen. En non-essentials als extra, dus via esp's, wired terug naar de meterkast kunnen communiceren. Hiervoor het ik een concept geschetst op github.

[Afbeelding]

https://github.com/meijer3/socket_plc (hier staat nog veel meer in de readme.md )

Er zijn nog een paar punten die voor mij onzeker zijn.
1. Hoe ik van 24v zuinig naar 3.3v kan (ben niet zo goed met pcb's)
2. Rx/Tx via esp door een ethernetkabel naar de meterkast kan communiceren. Modbus misschien?
3. Watt verbruik meten met de esp van de 230v.

Aanvullingen suggesties zijn welkom (eigenlijk hoop ik dat we de koppen bij elkaar kunnen steken).

En prototype twee is dan een ethernet kabel naar een raam, en dan de blinds regelen + 2 lokale knoppen + mogelijkheid voor een esp lokaal.

ps. idee is om kompleet wired te zijn

Als ik je dan een tip mag geven. https://www.olimex.com/Pr...-POE/open-source-hardware Dit zijn esp32's die wired zijn en ineens gevoed worden met POE.
Ik ben deze zelf aan het testen en zowat hetzelfde als jij van plan.

[Septillion]

@meijer3 Verdient misschien zelfs wel eigen topic in MME

Maar voor de vragen:

1. Overal van 24V terug naar 3v3 is misschien wat veel maar met een DCDC prima te doen. Als alternatief zou je misschien een centrale 5V voeding kunnen maken en de printen simpelweg van een LDO naar de 3v3 kunnen voorzien. Beetje compromis tussen zuinigheid en complexiteit denk ik.
2. Modbus is een protocol, geen elektrische spec. De UART zou ik niet zo 3v3 TTL over een kabel doen. Daar zou ik RS485 of CAN voor pakken.

Overigens lijkt me voor de toepassing een ESP ook wel overkill. Ook al kan deze met Wifi uit best zuinig zijn.

[meijer3]

bartw2604 schreef op vrijdag 26 augustus 2022 @ 10:53:
[...]


Als ik je dan een tip mag geven. https://www.olimex.com/Pr...-POE/open-source-hardware Dit zijn esp32's die wired zijn en ineens gevoed worden met POE.
Ik ben deze zelf aan het testen en zowat hetzelfde als jij van plan.

Ja mooi concept, dat was precies waar ik ook eerst aan dacht. Ik heb alleen een angst voor de domotica-moeheid. https://gathering.tweakers.net/forum/list_messages/1876227. Daarom moet gewoon de essentials altijd werken (vanuitgaande dat de PLC betrouwbaar is). Home assistant is voor mij lang niet betrouwbaar genoeg. Maar door de internet kabel te delen met de PLC dan ben ik niet afhankelijk meer van mqtt/home-assistant of het internet. Maar zijn we dan wel flexible en kunnen we esp's inzetten

Een ander alternatief is, dan de ESP laten luisteren naar de 24v IO van de PLC. maar dan heb je meer kabels nodig in de muur. (1 ethernet, en 1 voor PLC). Dan kan je ook de 24v van de PLC gebruiken

[MichVw]

Ik ben een hele tijd geleden gestart met deze modbus sensorhub:
https://github.com/Michie...mation.ModbusRtuSensorHub

de principes zijn hetzelfde denk ik; alles wat lowlevel houden en lokaal houden om domotica-moeheid te mijden. Alhoewel het bordje perfect werkt ben er echter niet verder mee gegaan omdat:
- mijn use case was om een sensornetwerk aan te leggen die rechtstreeks op de PLC kan aangesloten. De Esera modbus gateway heeft dat probleem echter voor me opgelost.
- PCB's ontwerpen kan ik niet, heb hulp gekeregen voor wat in de repo staat..
- PCB's solderen duurt een eeuwigheid als het al lukt (ligt ook aan mij ).
- ze bestukt bestellen word rap prijzig voor zower ik weet.

als je interesse hebt mag je de repo gerust overnemen. Ik ging hem in de nabije toekomst toch archiveren.

Rolluiken doe ik gewoon bedraad naar de kast, aansturen doe ik persoonlijk via lang drukken op een drukknop. Zo kan ik één drukknop gebruiken voor aansturen licht maar ook voor rolluiken.

[Kanze]

meijer3 schreef op vrijdag 26 augustus 2022 @ 10:44:
Met deze topic in gedachten, PLCs als core. Kan ik ook niet los laten hoe makkelijk esp/esphome is. Daarom was ik een repo begonnen met het ontwerp van een mini-PLC-controller.

Het idee is dat we de essentials via PLC doen. En non-essentials als extra, dus via esp's, wired terug naar de meterkast kunnen communiceren. Hiervoor het ik een concept geschetst op github.

[Afbeelding]

https://github.com/meijer3/socket_plc (hier staat nog veel meer in de readme.md )

Er zijn nog een paar punten die voor mij onzeker zijn.
1. Hoe ik van 24v zuinig naar 3.3v kan (ben niet zo goed met pcb's)
2. Rx/Tx via esp door een ethernetkabel naar de meterkast kan communiceren. Modbus misschien?
3. Watt verbruik meten met de esp van de 230v.

Aanvullingen suggesties zijn welkom (eigenlijk hoop ik dat we de koppen bij elkaar kunnen steken).

En prototype twee is dan een ethernet kabel naar een raam, en dan de blinds regelen + 2 lokale knoppen + mogelijkheid voor een esp lokaal.

ps. idee is om kompleet wired te zijn

Top project en heel gelijkaardig aan wat ik zelf in gebruik heb.

Hier zijn het ESP32's die vooral als dimmers dienen. Communicatie is via Modbus RTU over een enkele UTP kabel. Indien er interesse is wil ik gerust het prototype hier eens komen posten.

[Thyraon]

Hi all! Ik ben bezig plannen te maken voor een nieuw te bouwen huis en daarbij wil ik – geïnspireerd door de blogs en video's van Femme – een bedraad domoticasysteem in elkaar zetten.

Ik heb tweedehands een Wago 750-8100, een hele rits input/output-modules én een e!Cockpit licentie op de kop getikt, dus ik kan aan de slag om een testopstelling te maken. Als dat goed gaat, ga ik proberen in de nieuwe woning het leidingwerk meteen in een "ster-structuur" te laten leggen.



Ik kom hier binnenkort vast wel langs met m'n beginnersvragen

EDIT: meteen een eerste vraag: is soepel installatiedraad met 4mm² kern voldoende om de Wago PLC op de voeding en de modules aan te sluiten?

[ Voor 10% gewijzigd door Thyraon op 05-09-2022 13:24 ]

[THM0]

Thyraon schreef op maandag 5 september 2022 @ 13:21:

EDIT: meteen een eerste vraag: is soepel installatiedraad met 4mm² kern voldoende om de Wago PLC op de voeding en de modules aan te sluiten?

Voor 24V is dat nogal zwaar bemeten.

[Thyraon]

THM0 schreef op maandag 5 september 2022 @ 13:30:
Voor 24V is dat nogal zwaar bemeten.

Welke dikte draad zou ik beter kunnen gebruiken, denk je?

[MewBie]

Thyraon schreef op maandag 5 september 2022 @ 13:54:
[...]


Welke dikte draad zou ik beter kunnen gebruiken, denk je?

Als je in de documentatie kijkt zul je zien dat je maximaal 1,5mm^2 aan kunt sluiten.

[Thyraon]

MewBie schreef op maandag 5 september 2022 @ 14:12:
Als je in de documentatie kijkt zul je zien dat je maximaal 1,5mm^2 aan kunt sluiten.

Thanks! In de documentatie staat dat echter niet, voor zover ik kan zien. Ze benoemen wel dat de "CAGE CLAMP" connectors werken met "solid, stranded, and finely stranded conductors", en:

Select conductor cross sections as required for current load!
The current consumed for field-side supply may not exceed 10 A. The wire cross sections must be sufficient for the maximum current load for all of the I/O modules to be supplied with power.

Maar dus niet dat er maximaal 1,5mm² gebruikt mag worden.

[THM0]

Thyraon schreef op maandag 5 september 2022 @ 14:21:
[...]


Thanks! In de documentatie staat dat echter niet, voor zover ik kan zien. Ze benoemen wel dat de "CAGE CLAMP" connectors werken met "solid, stranded, and finely stranded conductors", en:


[...]


Maar dus niet dat er maximaal 1,5mm² gebruikt mag worden.

0.75mm2 is echt prima voor het 24V deel. Ik zou je wel even verdiepen in de basisconcepten van elektronica zoals spanning, stroom, vermogen etc zodat je niet alleen de handleiding leest maar ook daadwerkelijk begrijpt hoe eea aan te sluiten en waarom iets wel/niet een goed idee is...

[MewBie]

Thyraon schreef op maandag 5 september 2022 @ 14:21:
[...]


Thanks! In de documentatie staat dat echter niet, voor zover ik kan zien. Ze benoemen wel dat de "CAGE CLAMP" connectors werken met "solid, stranded, and finely stranded conductors", en:


[...]


Maar dus niet dat er maximaal 1,5mm² gebruikt mag worden.

https://www.wago.com/mx-e...troller-pfc100/p/750-8100
Je moet even weten hoe je de connection data tabel moet lezen, die had wat duidelijker gemogen...
Op die pagina kun je ook de nodige libraries en firmware downloaden mocht je dat nodig hebben.

[Thyraon]

Thanks, beiden! Ik ga lekker pielen

[Rob Z]

0.75mm2 is echt prima voor het 24V deel. Ik zou je wel even verdiepen in de basisconcepten van elektronica zoals spanning, stroom, vermogen etc zodat je niet alleen de handleiding leest maar ook daadwerkelijk begrijpt hoe eea aan te sluiten en waarom iets wel/niet een goed idee is...

Hier 0,5mm2 gebruikt voor alle 24V / 12V / 5V.
In de industrie is 1mm2 vrij gangbaar voor stuurstroom in panelen.

[Kanze]

Thyraon schreef op maandag 5 september 2022 @ 13:21:
Hi all! Ik ben bezig plannen te maken voor een nieuw te bouwen huis en daarbij wil ik – geïnspireerd door de blogs en video's van Femme – een bedraad domoticasysteem in elkaar zetten.

Ik heb tweedehands een Wago 750-8100, een hele rits input/output-modules én een e!Cockpit licentie op de kop getikt, dus ik kan aan de slag om een testopstelling te maken. Als dat goed gaat, ga ik proberen in de nieuwe woning het leidingwerk meteen in een "ster-structuur" te laten leggen.

[Afbeelding]

Ik kom hier binnenkort vast wel langs met m'n beginnersvragen

EDIT: meteen een eerste vraag: is soepel installatiedraad met 4mm² kern voldoende om de Wago PLC op de voeding en de modules aan te sluiten?

Te laat voor jouw maar toch nog eens vermelden voor anderen. Je hoeft geen ecockpit licentie te kopen. Je kan de software 30 dagen gratis gebruiken in een virtual machine en na 30 dagen gewoon die VM resetten.

Doe het zelf al jaren zo.

[Thyraon]

Kanze schreef op dinsdag 6 september 2022 @ 16:50:
Te laat voor jouw maar toch nog eens vermelden voor anderen. Je hoeft geen ecockpit licentie te kopen. Je kan de software 30 dagen gratis gebruiken in een virtual machine en na 30 dagen gewoon die VM resetten.

Ah, thanks, dat wist ik inderdaad niet. Oh well, ik heb al deze spullen voor een prima prijs kunnen overnemen dus vind het niet heel erg.

[Thyraon]

Ik heb een eerste testopstelling werkend: een fysieke aan/uit knop die een lamp schakelt via de Wago PLC input en output modules en een Eltako relais. Meest omslachtige manier om een lamp aan te doen ooit

Ik probeer nu met Node-RED (via Modbus) de status van een variabele uit te lezen maar dat krijg ik niet voor elkaar: ik zie in Node-RED steeds de foutmelding "Illegal data address (register not supported by device)".

In e!Cockpit zie ik een paar default Modbus variabelen die beschikbaar zijn, die kan ik wel uitlezen in Node-RED. De Modbus-communicatie werkt dus wel, het lijkt mis te gaan op mijn eigengemaakte variabele.

Ik heb in de "Modbus slave" tab in e!Cockpit voor de PLC een nieuw Data Point gemaakt, onder "Program variables", die gemapped is naar een BOOL variabele in mijn programma. Het "Modbus address" zou "Register: 0 Bit: 0" moeten zijn volgens e!Cockpit maar ik krijg die waarde met geen mogelijkheid uitgelezen in Node-RED.

Iemand hier die ervaring heeft met Node-RED en Modbus, en me misschien in de juiste richting kan helpen? Thanks!

[kuhlivisj]

Je moet in e!COCKPIT in de network view een generic modbus master toevoegen en die verbinden met de plc. Als je dat niet hebt dan wordt de modbus slave functionaliteit niet geactiveerd in de PLC.

[MewBie]

Thyraon schreef op zaterdag 10 september 2022 @ 22:25:
Ik heb een eerste testopstelling werkend: een fysieke aan/uit knop die een lamp schakelt via de Wago PLC input en output modules en een Eltako relais. Meest omslachtige manier om een lamp aan te doen ooit

Ik probeer nu met Node-RED (via Modbus) de status van een variabele uit te lezen maar dat krijg ik niet voor elkaar: ik zie in Node-RED steeds de foutmelding "Illegal data address (register not supported by device)".

In e!Cockpit zie ik een paar default Modbus variabelen die beschikbaar zijn, die kan ik wel uitlezen in Node-RED. De Modbus-communicatie werkt dus wel, het lijkt mis te gaan op mijn eigengemaakte variabele.

Ik heb in de "Modbus slave" tab in e!Cockpit voor de PLC een nieuw Data Point gemaakt, onder "Program variables", die gemapped is naar een BOOL variabele in mijn programma. Het "Modbus address" zou "Register: 0 Bit: 0" moeten zijn volgens e!Cockpit maar ik krijg die waarde met geen mogelijkheid uitgelezen in Node-RED.

Iemand hier die ervaring heeft met Node-RED en Modbus, en me misschien in de juiste richting kan helpen? Thanks!

En vanwege verschillende modbus implementaties kan het zijn dat je bepaalde offsets moet gebruiken. Hoe het precies zit met Wago PLCs weet ik niet, maar het kan zijn dat het eerste binaire register zit op 0, 1, 10000, of 10001. En ook afhankelijk van de implementatie kan het zijn dat je nog een waarde moet sturen om aan te geven met wat voor data je werkt. Het is al een tijdje geleden dat ik in zulk detail met modbus gewerkt heb...

[Thyraon]

kuhlivisj schreef op zondag 11 september 2022 @ 21:43:
Je moet in e!COCKPIT in de network view een generic modbus master toevoegen en die verbinden met de plc. Als je dat niet hebt dan wordt de modbus slave functionaliteit niet geactiveerd in de PLC.

AWW YISSS, dat was het inderdaad! Heel erg bedankt voor de tip, ik vond daarmee deze video met uitleg van precies de stappen die je beschrijft.

Voor hen die na mij komen, zo heb ik het nu aan elkaar geknoopt:

In e!Cockpit
- Een variabele gedeclareerd die in een IF/ELSE blok gebruikt wordt om de fysieke output op de Wago aan of uit te schakelen
- In de "Network/Devices" tab (na dubbelklik op de PLC), onder "Modbus slave" voor deze variabele een Modbus mapping gemaakt, als Coil (die krijgt standaard het adres 32768)
- In de "Network/Devices" tab een "Generic Modbus Master" toegevoegd en gekoppeld aan de PLC, zoals door @kuhlivisj getipt en hier uitgelegd
- Deze applicatie gedownload naar de PLC, en gestart

In Node-RED
- De "node-red-contrib-modbus" package geïnstalleerd
- Een Modbus Read node gemaakt die "FC1: Read Coil Status" gebruikt op Address 32768 (het adres van de Input/Output Coil) met Quantity 1. Deze node output simpelweg naar een Debug node.
- Een Modbus Write node gemaakt die "FC5: Force Single Coil" gebruikt, wederom op Address 32768. Hier staan twee boolean Inject nodes voor, met "true" en "false"

Door op de "true" inject node te klikken, wordt via Modbus de variabele in de PLC "true", en gaat de lamp aan. Die status zie je meteen terug in Node-RED uit de Modbus Read node. En vice verse, door de "false" inject node aan te klikken wordt de variabele via Modbus "false", gaat de lamp uit, en zie je die status weer in het debug window updaten in Node-RED.

Nogmaals dank voor de hulp! Ik ga weer verder klussen

[TLDNL]

Je zou ook naar netvars (network variables) kunnen kijken. Is wellicht wat makkelijker dan modbus.
Kurt Braun heeft er een filmpje over gemaakt.
YouTube: Using Node-RED with Network Variables

[Thyraon]

Thanks! Ik ben inmiddels een stapje verder gegaan en heb met de HomeAutomation library van @MichVw aansturing via MQTT werkend.

Dat wil zeggen: ik kan door het publishen van MQTT berichten (vanaf de command line en vanuit Node-RED) een digitale output (en daarmee een lamp op een relais) aan en uit zetten.

Wat me alleen nog niet lukt is diezelfde lamp via een fysieke knop (op een digitale input) schakelen. Als ik de knop omzet, zie ik een MQTT bericht vanaf de PLC binnenkomen op m'n broker (die zegt: de digitale input is nu aan) en ik zie in e!Cockpit in "PLC_PRG_MAIN.READ_PUSHBUTTONS" ook de "FB_DI_PB_001" PB waarde "TRUE" worden, maar de lamp gaat niet aan.

In "PLC_PRG_MAIN.WRITE_SWITCHES" is "FB_DO_SW_001" geconfigureerd met "TOGGLE := FB_DI_PB_001.SINGLE" maar die "SINGLE" waarde wordt niet "TRUE" als ik de knop omzet. De "PB" en "P_LONG" waarden worden wel "TRUE" maar als ik die gebruik om de digitale output mee te togglen, gaat m'n relais supersnel achter elkaar aan/uit. Dat lijkt dus niet de juiste manier te zijn.

@MichVw waarschijnlijk heb ik iets heel evidents over het hoofd gezien, kun jij me misschien in de juiste richting wijzen?

EDIT: wellicht goed om op te merken dat ik hier een eenvoudige aan/uit schakelaar gebruik, dus geen pulsdrukker, op de digitale input. Misschien maakt dat het verschil?

[ Voor 6% gewijzigd door Thyraon op 13-09-2022 22:37 ]

[Giblet]

Thyraon schreef op dinsdag 13 september 2022 @ 22:34:
Thanks! Ik ben inmiddels een stapje verder gegaan en heb met de HomeAutomation library van @MichVw aansturing via MQTT werkend.

Dat wil zeggen: ik kan door het publishen van MQTT berichten (vanaf de command line en vanuit Node-RED) een digitale output (en daarmee een lamp op een relais) aan en uit zetten.

Wat me alleen nog niet lukt is diezelfde lamp via een fysieke knop (op een digitale input) schakelen. Als ik de knop omzet, zie ik een MQTT bericht vanaf de PLC binnenkomen op m'n broker (die zegt: de digitale input is nu aan) en ik zie in e!Cockpit in "PLC_PRG_MAIN.READ_PUSHBUTTONS" ook de "FB_DI_PB_001" PB waarde "TRUE" worden, maar de lamp gaat niet aan.

In "PLC_PRG_MAIN.WRITE_SWITCHES" is "FB_DO_SW_001" geconfigureerd met "TOGGLE := FB_DI_PB_001.SINGLE" maar die "SINGLE" waarde wordt niet "TRUE" als ik de knop omzet. De "PB" en "P_LONG" waarden worden wel "TRUE" maar als ik die gebruik om de digitale output mee te togglen, gaat m'n relais supersnel achter elkaar aan/uit. Dat lijkt dus niet de juiste manier te zijn.

@MichVw waarschijnlijk heb ik iets heel evidents over het hoofd gezien, kun jij me misschien in de juiste richting wijzen?

EDIT: wellicht goed om op te merken dat ik hier een eenvoudige aan/uit schakelaar gebruik, dus geen pulsdrukker, op de digitale input. Misschien maakt dat het verschil?

Volgens mij gebruiken de meeste van ons pushbuttons/pulsdrukkers. Deze maken maar kort contact (meestal minder dan 250 ms, ik hou zelf 1000ms aan uit m'n hoofd). Hiermee kan je dan ook dubbel-kliks en triple-kliks (hence the 1000ms) registreren, waardoor die ene schakelaar meerdere functies toebedeeld kan krijgen.

Wanneer je een schakelaar hebt die niet vanzelf teruggaat naar de "false" positie kan dit gedrag volgens mij optreden... Probeer eens snel achter elkaar aan en uit te doen, grote kans dat het dan werkt.

[ Voor 4% gewijzigd door Giblet op 14-09-2022 09:03 ]

[Thyraon]

Giblet schreef op woensdag 14 september 2022 @ 09:02:
Volgens mij gebruiken de meeste van ons pushbuttons/pulsdrukkers. Deze maken maar kort contact (meestal minder dan 250 ms, ik hou zelf 1000ms aan uit m'n hoofd). Hiermee kan je dan ook dubbel-kliks en triple-kliks (hence the 1000ms) registreren, waardoor die ene schakelaar meerdere functies toebedeeld kan krijgen.

Wanneer je een schakelaar hebt die niet vanzelf teruggaat naar de "false" positie kan dit gedrag volgens mij optreden... Probeer eens snel achter elkaar aan en uit te doen, grote kans dat het dan werkt.

Thanks, ik vermoed ook dat dat het probleem is, vooral door deze regel in de documentatie van de HomeAutomation library:

SINGLE: output high for one clock cycle when a single push is detected on input PB

Ik heb maar gewoon een pulsdrukker besteld, dat is uiteindelijk toch ook wat ik in mijn woning zou gebruiken. Als PostNL zometeen langs is geweest, kan ik kijken of dat het oplost

[Thyraon]

Giblet schreef op woensdag 14 september 2022 @ 09:02:
Probeer eens snel achter elkaar aan en uit te doen, grote kans dat het dan werkt.

Ha, dat werkt inderdaad! Dan gaat het met een pulsdrukker zeker werken, dank voor de tip!

[Thyraon]

Yes! PostNL kwam net de pulsdrukker brengen en daarmee werkt het vlekkeloos. Ik kan nu dus een lamp aan/uit zetten met de fysieke knop én via MQTT (bijvoorbeeld via een Node-RED dashboard op m'n telefoon).

Next up: wachten tot m'n Wago analoge output-module wordt geleverd zodat ik een dimmer kan aansturen.

[MichVw]

Thyraon schreef op woensdag 14 september 2022 @ 13:30:
Yes! PostNL kwam net de pulsdrukker brengen en daarmee werkt het vlekkeloos. Ik kan nu dus een lamp aan/uit zetten met de fysieke knop én via MQTT (bijvoorbeeld via een Node-RED dashboard op m'n telefoon).

Next up: wachten tot m'n Wago analoge output-module wordt geleverd zodat ik een dimmer kan aansturen.

de meeste logica is inderdaad gemaakt om met drukknoppen te werken. Je kan er gewoon veel meer mee doen. uit ervaring moet ik toegeven dat de dubblepush functionaliteit moeilijk te gebruiken is omdat je wel echt rap dubbel moet drukken. De long push gebruik ik overal, waar er rolluiken zijn gebruik ik de long push om de rolluiken aan te sturen, waar er buitenverlichting is gebruik ik die voor de buitenverlichting. Spaart een hoop schakelaars/kabels enzo uit. (en ik kan toch nooit onthouden welke schakelaar voor de buitenverlichting was )

[Thyraon]

MichVw schreef op donderdag 15 september 2022 @ 12:17:
de meeste logica is inderdaad gemaakt om met drukknoppen te werken. Je kan er gewoon veel meer mee doen. uit ervaring moet ik toegeven dat de dubblepush functionaliteit moeilijk te gebruiken is omdat je wel echt rap dubbel moet drukken. De long push gebruik ik overal, waar er rolluiken zijn gebruik ik de long push om de rolluiken aan te sturen, waar er buitenverlichting is gebruik ik die voor de buitenverlichting. Spaart een hoop schakelaars/kabels enzo uit. (en ik kan toch nooit onthouden welke schakelaar voor de buitenverlichting was )

Het viel me op dat de double push wel heel nauw luistert. Is die timing in de software nog aan te passen? En hoe stuur jij je dimmers aan? Met een long push op een pulsdrukker (waarbij de dimmer van zacht naar hard gaat, en weer terug) of heb je dubbele pulsdrukkers met aparte "harder" en "zachter" knoppen?

[Rob Z]

Thyraon schreef op donderdag 15 september 2022 @ 16:32:
[...]


Het viel me op dat de double push wel heel nauw luistert. Is die timing in de software nog aan te passen? En hoe stuur jij je dimmers aan? Met een long push op een pulsdrukker (waarbij de dimmer van zacht naar hard gaat, en weer terug) of heb je dubbele pulsdrukkers met aparte "harder" en "zachter" knoppen?

Geen vraag aan mij, maar de dimmers heb ik hier ingesteld in stappen. Met elke klik een stap (5 stappen) feller van minimaal tot voluit, en weer uit. (long press is tevens uit)

[Thyraon]

Rob Z schreef op donderdag 15 september 2022 @ 16:40:
Geen vraag aan mij, maar de dimmers heb ik hier ingesteld in stappen. Met elke klik een stap (5 stappen) feller van minimaal tot voluit, en weer uit. (long press is tevens uit)

Ah, cool, dat is ook een goede manier om het te doen. Overigens zou ik die dimmers misschien niet eens vaak hoeven aanpassen met de knoppen – mijn huidige woning hangt vol met Hue-lampen en daar wisselen we eigenlijk alleen maar tussen 2-3 vaste programma's per kamer.

Kan me voorstellen dat ik dat zometeen op de PLC ook op die manier inricht, en dan de pulsdrukkers koppel aan de verschillende presets.

[ Voor 12% gewijzigd door Thyraon op 15-09-2022 17:24 ]

[Thyraon]

@Rob Z by the way, heb je die 5 stappen, en het daar doorheen lopen met een pulsdrukker, ook rechtstreeks op een PLC geprogrammeerd? Of stuur je dat aan via Node-RED of een andere tool?

[Rob Z]

@Thyraon Ja, de dimnivo's zijn hard coded in de PLC

[Giblet]

Als ik het me goed herinner heb ik de tijd waarop een long-push wordt gedetecteerd toen kunnen veranderen naar 1000ms. Hierdoor is een dubbelklik makkelijker te detecteren (ik heb tevens zelf ook nog triple-klik toegevoegd). Dat het dan langer duurt voordat het dimmen start neem ik voor lief. Voor het dimmen zelf gebruik ik de schakelaars meestal niet, maar mijn domotica applicatie.

De dubbelklik bij dimmers is dan zo geprogrammeerd dat deze in de PLC wisselt tussen de min-waarde en de max-waarde uit @MichVw's applicatie. Weet even de exacte bewoording die daarvoor gebruikt wordt niet meer.

Dus bij de meeste dimmers is het als volgt ingesteld:
- Minimale waarde 60% intensiteit
- Maximale waarde 100% intensiteit

1 keer klikken schakelt dan tussen minimale waarde en uit
2 keer klikken schakelt dan tussen minimale waarde en maximale waarde
3 keer klikken niet gedefinieerd in de PLC

Omdat alle schakelaar activiteit ook via MQTT gepubliceerd wordt kan je op een ander niveau wel/niet besluiten om iets in je domotica server te doen. Zo heb ik de long-push in de slaapkamer ingesteld dat het huis op de nachtstand gaat.

Voor mijn use case werkt het perfect om de vrijheid te hebben om te bepalen of iets in de PLC moet gebeuren (alle hard-wired verlichting zegmaar...) of in de domotica server, waar bijvoorbeeld ook tradfri verlichting op aangesloten is.

[Thyraon]

Giblet schreef op vrijdag 16 september 2022 @ 12:34:
Voor mijn use case werkt het perfect om de vrijheid te hebben om te bepalen of iets in de PLC moet gebeuren (alle hard-wired verlichting zegmaar...) of in de domotica server, waar bijvoorbeeld ook tradfri verlichting op aangesloten is.

Ja, dat lijkt mij ook een mooie splitsing tussen wel/niet rechtstreeks aansturen vanaf de PLC: verlichting (en misschien ook screens) direct op de PLC, alle andere slimme spullen aansturen via Node-RED en/of HomeAssistant.

[MichVw]

Thyraon schreef op donderdag 15 september 2022 @ 16:32:
[...]


Het viel me op dat de double push wel heel nauw luistert. Is die timing in de software nog aan te passen? En hoe stuur jij je dimmers aan? Met een long push op een pulsdrukker (waarbij de dimmer van zacht naar hard gaat, en weer terug) of heb je dubbele pulsdrukkers met aparte "harder" en "zachter" knoppen?

klopt, er is inderdaad een setting in de pushbutton input FB waar je wat mee kunt spelen. Zelf heb ik hier nog niet de tijd voor gevonden. Laat gerust weten als je een waarde vind waar je tevreden mee bent, minder zoekwerk voor mij

ik heb (nog) geen dimmers, hier vind je wel een code sample voor het aansturen een dimmer:
https://github.com/Michie...MMER_MQTT.md#code-example

de dimmer FB is gebouwd met als basis een FB uit de OSCAT lib, als je de FB opendrukt zal je zien welke FB specifiek (heb even niet m'n laptop met éCockpit bij de hand).

OSCAT building docs vind je hier:
https://github.com/Michie.../oscat_building100_en.pdf

[Thyraon]

Thanks @MichVw, zodra ik de lampen heb die ik wil gaan gebruiken in de woning zal ik daarmee gaan spelen. De drie euro LED die ik nu gebruik, heeft een te beperkte range qua dimbaarheid om die waarden nuttig mee te testen.

Maar m'n eerste echte testopstelling werkt nu! Thanks @KoBolD54 voor de foto van jouw testopstelling, die heb ik nu zo'n beetje nagebouwd. Een relais achter een digitale output van de Wago en een dimmer daarachter, op de analoge output. Werkt perfect met de fysieke pulsdrukker of via MQTT met Node-RED (of een Linux command line MQTT publisher )

Nu alleen nog een huis bouwen en de hele boel opschalen

[Kanze]

Thyraon schreef op donderdag 15 september 2022 @ 16:32:
[...]


Het viel me op dat de double push wel heel nauw luistert. Is die timing in de software nog aan te passen? En hoe stuur jij je dimmers aan? Met een long push op een pulsdrukker (waarbij de dimmer van zacht naar hard gaat, en weer terug) of heb je dubbele pulsdrukkers met aparte "harder" en "zachter" knoppen?

Een double push is niets meer als een single push met een interne timer. Als er binnen de periode van die timer een tweede signaal binnen komt wordt dat als een double push geïnterpreteerd. Je kan die periode gewoon in de code aanpassen.

[Kanze]

Update: Ik vermeld het hier voor wie later op hetzelfde probleem stoot. De éCockpit simulator (thans versie 1.11.0.2) kan de MQTT communicatie meter de broker niet simuleren. Onderstaande code draait wel zoals het hoort op de effectieve hardware PLC.

----

@MichVw ik heb wat hulp nodig om het MQTT aspect van je project te begrijpen.

In een poging dat te doorgronden heb ik het project teruggebracht tot zuiver de MQTT implementatie op basis van Stefan's MQTT library en een enkele instantie van de subscriber FB. Wat nog overschiet is dan;

code:

PLC_PRG_MQTT
    MQTT_INIT
    MQTT_SUBSCRIBE

subscriber_FB_MQTT:MQTT.MQTTSubscribe

De hoofdvraag is of de MQTT implementatie kan gesimuleerd worden in de éCockpit simulator? Het programma start op in de simulator zonder foutmeldingen stapt door de INIT fase om dan in de SUBSCRIBE loop te gaan. Maar op mijn lokale MQTT broker zie ik geen poging tot connectie binnen komen. De lokale broker is geverifieerd OK door andere software.

Ik plaats nog screenshots ter verduidelijking. Wat begrijp ik hier niet?

[ Voor 7% gewijzigd door Kanze op 26-10-2022 19:58 ]

[MichVw]

Kanze schreef op woensdag 26 oktober 2022 @ 14:40:
Update: Ik vermeld het hier voor wie later op hetzelfde probleem stoot. De éCockpit simulator (thans versie 1.11.0.2) kan de MQTT communicatie meter de broker niet simuleren. Onderstaande code draait wel zoals het hoort op de effectieve hardware PLC.

----

@MichVw ik heb wat hulp nodig om het MQTT aspect van je project te begrijpen.

In een poging dat te doorgronden heb ik het project teruggebracht tot zuiver de MQTT implementatie op basis van Stefan's MQTT library en een enkele instantie van de subscriber FB. Wat nog overschiet is dan;

code:

PLC_PRG_MQTT
    MQTT_INIT
    MQTT_SUBSCRIBE

subscriber_FB_MQTT:MQTT.MQTTSubscribe

De hoofdvraag is of de MQTT implementatie kan gesimuleerd worden in de éCockpit simulator? Het programma start op in de simulator zonder foutmeldingen stapt door de INIT fase om dan in de SUBSCRIBE loop te gaan. Maar op mijn lokale MQTT broker zie ik geen poging tot connectie binnen komen. De lokale broker is geverifieerd OK door andere software.

Ik plaats nog screenshots ter verduidelijking. Wat begrijp ik hier niet?

[Afbeelding]

[Afbeelding]

[Afbeelding]

ik simuleer nooit, run altijd op effectieve hardware. Ik vrees dus dat ik je op dat punt niet echt kan helpen.
Mocht je andere vragen hebben voor het begrijpen van de MQTT logica hoor ik het wel.

[Kanze]

MichVw schreef op donderdag 27 oktober 2022 @ 13:35:
[...]


ik simuleer nooit, run altijd op effectieve hardware. Ik vrees dus dat ik je op dat punt niet echt kan helpen.
Mocht je andere vragen hebben voor het begrijpen van de MQTT logica hoor ik het wel.

Na anderhalf jaar eindelijk toegekomen aan de implementatie van een Home Assistant & PLC sturing aan de hand van het je excellent project @MichVw

Ik heb momenteel nog wel een use-case waar ik wat hulp bij kan gebruiken.

Ik heb een eigen LED dimmer ontworpen die via Modbus RTU wordt aangestuurd door de PLC. Binnen het HomeAutomation project heb ik een nieuwe FB gemaakt die zowel de RS485Device interface en de MQTT.MQTT_subscribe interfaces implementeert.

Home Assistant schrijft commando's naar een specifieke MQTT topic en de FB vertaalt die commando's naar een RtuQuery welke de dimmer vervolgens goed ontvangt. Alles werkt zoals het hoort.

Het probleem is dat de RS485 Bus Controller naast mijn dimmer nog 5 andere Eastrom SDM energiemeters onder zich heeft. De bus controller is dus vrij vaak bezig met die energiemeters te pollen. Dat zorgt ervoor dat mijn dimmer Function Block soms moet wachten alvorens het Bus Time krijgt van de controller. Dat zorgt ervoor dat tussen het verzenden van het MQTT commando en de effectieve dim actie van mijn dimmer er heel wat vertraging zit. Tot 15 seconden.

Hoe los ik dit best op? Bestaat er zoiets als een interrupt die de Rs485 bus controller dwingt van onmiddelijk mijn dimmer aan te sturen? Moet het in een andere taak met hogere priority?

Wat denk jij?

[MichVw]

Kanze schreef op zondag 30 oktober 2022 @ 11:11:
[...]


Na anderhalf jaar eindelijk toegekomen aan de implementatie van een Home Assistant & PLC sturing aan de hand van het je excellent project @MichVw

Ik heb momenteel nog wel een use-case waar ik wat hulp bij kan gebruiken.

Ik heb een eigen LED dimmer ontworpen die via Modbus RTU wordt aangestuurd door de PLC. Binnen het HomeAutomation project heb ik een nieuwe FB gemaakt die zowel de RS485Device interface en de MQTT.MQTT_subscribe interfaces implementeert.

Home Assistant schrijft commando's naar een specifieke MQTT topic en de FB vertaalt die commando's naar een RtuQuery welke de dimmer vervolgens goed ontvangt. Alles werkt zoals het hoort.

Het probleem is dat de RS485 Bus Controller naast mijn dimmer nog 5 andere Eastrom SDM energiemeters onder zich heeft. De bus controller is dus vrij vaak bezig met die energiemeters te pollen. Dat zorgt ervoor dat mijn dimmer Function Block soms moet wachten alvorens het Bus Time krijgt van de controller. Dat zorgt ervoor dat tussen het verzenden van het MQTT commando en de effectieve dim actie van mijn dimmer er heel wat vertraging zit. Tot 15 seconden.

Hoe los ik dit best op? Bestaat er zoiets als een interrupt die de Rs485 bus controller dwingt van onmiddelijk mijn dimmer aan te sturen? Moet het in een andere taak met hogere priority?

Wat denk jij?

Je hebt dus een implementatie die ook registers schrijft via modbus RTU? interessant, stond ook nog op m'n lijstje mocht je het zien zitten om een github issue aan te maken voor offcial support met je project in bijlage zou dat top zijn!

Betreffende je vraag: 15 seconden is wel heel lang. wat is de polling interval voor je 5 eastron meters? Wat ik als eerste zou proberen is om het registreren van je dimmer tegen de buscontroller te doen voor je eastron meters, bv:

code:

RS485BusController.RegisterDevice(device := FB_RS485_DIY_DIMMER_1);
RS485BusController.RegisterDevice(device := FB_RS485_DIY_DIMMER_2);
RS485BusController.RegisterDevice(device := FB_RS485_EASTRON_SDM220_1);
RS485BusController.RegisterDevice(device := FB_RS485_EASTRON_SDM220_2);
RS485BusController.RegisterDevice(device := FB_RS485_EASTRON_SDM220_3);
RS485BusController.RegisterDevice(device := FB_RS485_EASTRON_SDM220_4);
RS485BusController.RegisterDevice(device := FB_RS485_EASTRON_SDM220_5);

Dit gaat ervoor zorgen dat er eerst aan de dimmers gevraagd wordt of ze de bus nodig hebben voor de eastron meters.

Los daarvan vind ik 15 seconden wel nog altijd veel maar het is moeilijk te zeggen of het logisch is of niet zonder de polling interval te weten.

[Kanze]

MichVw schreef op woensdag 2 november 2022 @ 15:56:
[...]

Je hebt dus een implementatie die ook registers schrijft via modbus RTU? interessant, stond ook nog op m'n lijstje mocht je het zien zitten om een github issue aan te maken voor offcial support met je project in bijlage zou dat top zijn!

Ondertussen heb ik dit werkende gekregen zoals het hoort. Project is momenteel wat te slordig om op Github te gooien maar het idee is als volgt;

code:

FUNCTION_BLOCK FB_RLC700 IMPLEMENTS RS485Device, MQTT.MQTT_SUBSCRIBE_CALLBACK

METHOD PublishReceived : bool
VAR_INPUT
    (*Collection of recived Data*)
    Data    : MQTT.CALLBACK_DATA;
END_VAR

    THIS^.Set1RtuQuery.DeviceId         := Data.Payload[0];                 // DeviceID type BYTE
    THIS^.Set1RtuQuery.WriteAddress     := BYTE_TO_UINT(Data.Payload[1]);   
    THIS^.Set1RtuQuery.WriteQuantity    := uiWriteQuantity;
    THIS^.Set1RtuQuery.awWriteData[0]   := BYTE_TO_WORD(Data.Payload[2]);
    
    THIS^.xDimmerOverride := TRUE;

Commando komt binnen via MQTT. In mijn geval gewoon drie bytes (Dimmer Modbus ID, Kanaal, Helderheidspercentage).

code:

METHOD GetRtuQuery : RS485_RtuQuery

(* Set in PublishReceived -- Interupt normal publish cycle to set dimmer command *)
IF xDimmerOverride THEN
    xDimmerOverride := FALSE;
    THIS^.timerData1.IN := FALSE;           // Restarts normal publish cycle
    THIS^.ActiveRtuQuery := 6;
    GetRtuQuery := THIS^.Set1RtuQuery;
    RETURN;
END_IF

IF timerData1.Q THEN
    THIS^.timerData1.IN := FALSE;
    THIS^.ActiveRtuQuery := 1;
    GetRtuQuery := THIS^.Data1RtuQuery;
END_IF

Hier zorgt xDimmerOverride ervoor dat wanneer een MQTT commando ontvangen werd dit in de plaats van de reguliere status-update zal worden verstuurd. Wanneer er geen commando binnenkomt publiceert de dimmer standaard op interval de waarden van alle kanalen en de temperatuurhistoriek.

code:

IF Error^ THEN
    PubMqttMessage(Suffix := '/availability', Data := 'offline');
ELSE
    PubMqttMessage(Suffix := '/availability', Data := 'online');
END_IF

(* RS485 Buscontroller calls this function when it detects the Modbus command
has completed on the physical device *)

// Regular data response
IF ActiveRtuQuery = 1 THEN
    THIS^.Error1 := Error^;
    THIS^.timerData1.IN := TRUE;
    IF NOT Error^ THEN
        THIS^.oJsonStruct.DIMSPEED.Number := WORD_TO_UINT(Data^[0]);
        THIS^.oJsonStruct.CHANNEL1.Number := WORD_TO_UINT(Data^[1]);
        THIS^.oJsonStruct.CHANNEL2.Number := WORD_TO_UINT(Data^[2]);
        THIS^.oJsonStruct.CHANNEL3.Number := WORD_TO_UINT(Data^[3]);
        THIS^.oJsonStruct.CHANNEL4.Number := WORD_TO_UINT(Data^[4]);
        THIS^.oJsonStruct.CHANNEL5.Number := WORD_TO_UINT(Data^[5]);
        THIS^.oJsonStruct.CHANNEL6.Number := WORD_TO_UINT(Data^[6]);
        THIS^.oJsonStruct.CHANNEL7.Number := WORD_TO_UINT(Data^[7]);
        THIS^.oJsonStruct.TCURRENT.Number := SwapWordsToReal(Data^[8], Data^[9]);
        THIS^.oJsonStruct.TMIN.Number := SwapWordsToReal(Data^[10], Data^[11]);
        THIS^.oJsonStruct.TMAX.Number := SwapWordsToReal(Data^[12], Data^[13]);
        (* Triggers MQTT send-off *)
        THIS^.Update1 := TRUE;
    END_IF
END_IF

// Dimmercontrol response
IF ActiveRtuQuery = 6 THEN
    THIS^.Error1 := Error^;
    THIS^.timerData1.IN := TRUE;
END_IF

ActiveRtuQuery := 0;
ActiveDevice := FALSE;

Nadat het commando via Modbus is verzonden naar de dimmer wordt het status-update interval hernomen door timerData weer aan te zetten.

Eenvoudige implementatie maar het werkt nagenoeg in real-time. Die 15 seconden waar ik eerder over sprak hadden waarschijnlijk te maken met een gebrekkige eerste implementatie van het idee.

[Kanze]

Redelijk frustrerende dag vandaag met Home Assistant.

PLC's hebben hun eigen vorm van zwarte magie. Maar daar zou je nog kunnen stellen het gebrek aan duidelijke informatie het gevolg is van bedrijfsgeheimen en gewoon algemeen het idee dat PLC's programmeren nooit voor de consument werd bedoeld.

Home Assistant is een open source project waarvan de documentatie zo mogelijk nog slechter is dan die van de gemiddelde PLC. Jongens toch.

[TLDNL]

Waar loop je tegen aan dan Kanze? Ik wil de koppeling tzt ook gaan maken.

[Thyraon]

Als het om MQTT gaat: ik heb een opstelling met Node-RED en een Wago PLC werkend, misschien kan ik helpen

[Kanze]

TLDNL schreef op woensdag 9 november 2022 @ 17:52:
Waar loop je tegen aan dan Kanze? Ik wil de koppeling tzt ook gaan maken.

De avond was nog jong en ik ben dan iemand die het werk niet neer kan leggen. Ondertussen is het een stuk duidelijker. HA documentatie mist een duidelijk startpunt en een logische flow. Beetje zoals mijn boekhouding dus.


Na anderhalf jaar staat het fundament eindelijk goed.

1. Home Assistant en Mosquitto MQTT broker op een standalone Fedora Linux mini-PC. Alle top-level automatisatie, influxdb, wireguard tunnels, pihole, grafana, etc... zit daar.

2. PLC draait een baseline programma dat zorgt ervoor dat lichtschakelaars, rolluiken, poort etc... altijd hun basisfuncties kunnen uitvoeren.

3. PLC draait een onafhankelijk MQTT programma en spreekt zo met Home Assistant op de mini-PC. Communicatie verloopt heen en weer in JSON.

4. PLC draait een derde onafhankelijk RS485/Modbus programma en spreekt zo met energiemeters, warmtepomp, ventilatiestellen, en mijn eigen dimmers.

5. PLC heeft een interne brug waardoor Home Assistant MQTT commando's kan uitvaardigen die via de PLC vertaald worden en aan de juiste Modbus slave worden opgelegd. Antwoorden van de slave gaan via de omgekeerde weg. Communicatie verloopt in Realtime.

6. ESP32's functioneren als miniatuur-extensies van de PLC en zitten in dimmers binnen en buitenhuis. Momenteel spreken ze zuiver via Modbus met de PLC. Maar ik vermoed dat later via Wifi en direct via MQTT ook wel zal gebeuren .


Dit alles zou niet mogelijk geweest zijn zonder @MichVw en zijn fantastische HomeAutomation project als basis. Dat en het werk van Stefan Dreyer met z'n MQTT en JSON libraries

[meijer3]

Kanze schreef op donderdag 10 november 2022 @ 00:07:
[...]

Na anderhalf jaar staat het fundament eindelijk goed.

Dit alles zou niet mogelijk geweest zijn zonder @MichVw en zijn fantastische HomeAutomation project als basis. Dat en het werk van Stefan Dreyer met z'n MQTT en JSON libraries

Wat gaaf dat het allemaal gelukt is. Hopelijk draait het zonder problemen.
De documentatie van de PLC is inderdaad vrij laag, en soms ook vooral Duits.
Is je code opensource en/of zou je het willen delen? Ik denk (naast ik) er nog meer mensen het erg interessant vinden!

[bartw2604]

Kanze schreef op donderdag 10 november 2022 @ 00:07:
[...]


De avond was nog jong en ik ben dan iemand die het werk niet neer kan leggen. Ondertussen is het een stuk duidelijker. HA documentatie mist een duidelijk startpunt en een logische flow. Beetje zoals mijn boekhouding dus.


Na anderhalf jaar staat het fundament eindelijk goed.

1. Home Assistant en Mosquitto MQTT broker op een standalone Fedora Linux mini-PC. Alle top-level automatisatie, influxdb, wireguard tunnels, pihole, grafana, etc... zit daar.

2. PLC draait een baseline programma dat zorgt ervoor dat lichtschakelaars, rolluiken, poort etc... altijd hun basisfuncties kunnen uitvoeren.

3. PLC draait een onafhankelijk MQTT programma en spreekt zo met Home Assistant op de mini-PC. Communicatie verloopt heen en weer in JSON.

4. PLC draait een derde onafhankelijk RS485/Modbus programma en spreekt zo met energiemeters, warmtepomp, ventilatiestellen, en mijn eigen dimmers.

5. PLC heeft een interne brug waardoor Home Assistant MQTT commando's kan uitvaardigen die via de PLC vertaald worden en aan de juiste Modbus slave worden opgelegd. Antwoorden van de slave gaan via de omgekeerde weg. Communicatie verloopt in Realtime.

6. ESP32's functioneren als miniatuur-extensies van de PLC en zitten in dimmers binnen en buitenhuis. Momenteel spreken ze zuiver via Modbus met de PLC. Maar ik vermoed dat later via Wifi en direct via MQTT ook wel zal gebeuren .


Dit alles zou niet mogelijk geweest zijn zonder @MichVw en zijn fantastische HomeAutomation project als basis. Dat en het werk van Stefan Dreyer met z'n MQTT en JSON libraries

Ik ben exact hetzelfde van plan. Zou super zijn als je je project wil open sourcen.
Ik heb vooral ook interesse in je home made dimmers. Heb je dan verlichting op 24V?

[Kanze]

Vraag aan de specialisten. Ik zit met een vervelend probleem. Het lukt me niet om DO output variabelen in de aanroep van een functionblock te gebruiken.

Simpel voorbeeld. Ik heb een array van enkele DO output variabelen en ik wil die variabelen misschien TRUE of FALSE zetten binnen mijn function block.

Voorbeeldcode voor de FB

code:

VAR_IN_OUT
    DO_VARS : ARRAY[*] OF POINTER TO BOOL;
    INDEX : UINT;
END_VAR

FOR INDEX := 0 to SIZEOF(DO_VARS) DO
    DO_VARS[INDEX]^ := TRUE'

Stel dat ik in mijn hoofdprogramma het array DO variabelen declareer en ze bij de oproep
van mijn FB opgeef

code:

VAR
    GROEP_DO_VARIABELEN : ARRAY[0..1] OF POINTER TO BOOL := [
                                            ADR(DO_Variabel1),
                                            ADR(DO_Variabel2) ];
    
END_VAR

FB_INSTANCE(DO_VARS := GROEP_DO_VARIABELEN)

Wat er dan gebeurd is dat ADR een pointer geeft naar het volledige byte-address van de output-module en NIET naar het adres van individuele DO kannalen.

Hoe los ik dit op? Er moet toch een eenvoudige manier bestaan om DO output variabelen van het hoofdprogramma door te geven naar je function block? @MichVw ?

[Wafje]

Kanze schreef op donderdag 24 november 2022 @ 16:03:
Vraag aan de specialisten. Ik zit met een vervelend probleem. Het lukt me niet om DO output variabelen in de aanroep van een functionblock te gebruiken.

Simpel voorbeeld. Ik heb een array van enkele DO output variabelen en ik wil die variabelen misschien TRUE of FALSE zetten binnen mijn function block.

Voorbeeldcode voor de FB

code:

VAR_IN_OUT
    DO_VARS : ARRAY[*] OF POINTER TO BOOL;
    INDEX : UINT;
END_VAR

FOR INDEX := 0 to SIZEOF(DO_VARS) DO
    DO_VARS[INDEX]^ := TRUE'

Stel dat ik in mijn hoofdprogramma het array DO variabelen declareer en ze bij de oproep
van mijn FB opgeef

code:

VAR
    GROEP_DO_VARIABELEN : ARRAY[0..1] OF POINTER TO BOOL := [
                                            ADR(DO_Variabel1),
                                            ADR(DO_Variabel2) ];
    
END_VAR

FB_INSTANCE(DO_VARS := GROEP_DO_VARIABELEN)

Wat er dan gebeurd is dat ADR een pointer geeft naar het volledige byte-address van de output-module en NIET naar het adres van individuele DO kannalen.

Hoe los ik dit op? Er moet toch een eenvoudige manier bestaan om DO output variabelen van het hoofdprogramma door te geven naar je function block? @MichVw ?

Een pointer wijst naar een adres met de grootte van 1 byte. Een BOOL is daar één 8ste van.
Ik weet niet zeker of de compiler één adres voorziet per array entry (in het geval van een BOOL).

Kan je eens proberen om je booleans te mappen naar een BYTE?

[MichVw]

Wafje schreef op donderdag 24 november 2022 @ 18:14:
[...]


Een pointer wijst naar een adres met de grootte van 1 byte. Een BOOL is daar één 8ste van.
Ik weet niet zeker of de compiler één adres voorziet per array entry (in het geval van een BOOL).

Kan je eens proberen om je booleans te mappen naar een BYTE?

klopt, je kan waarschijnlijk ook werken met bit shifting operations om om één bit (= 1 DO) in de byte te setten.

[jellevictoor]

Ik heb een bijgebouw die ik ook wil aansluiten aan mijn domotica.
ik heb nu een 750-881 waarop alles draait. Kan ik een pcf200 kopen, hierop alles programmeren en mijn 750-881 als domme slave gebruiken die enkel inputs kan aan en uit zetten? Ik zou graag hebben dat mijn programma draait op mijn pcf200 omdat die toch wat moderner is qua interface.

verbind ik die beide dan via ethernet? of moet het via een ander protocol?

[TLDNL]

Je hebt meerdere opties:
1) de 881 koppelen via modbus TCP en de IO’s benoemen als variabelen in e!cockpit
2) de 881 stand alone laten draaien maar variabelen uitwisselen via netvars
3) de 881 houden en in je bijgebouw een ethernet coupler plaatsen met IO’s. Bijv de 750-362

[jellevictoor]

TLDNL schreef op woensdag 30 november 2022 @ 18:47:
Je hebt meerdere opties:
1) de 881 koppelen via modbus TCP en de IO’s benoemen als variabelen in e!cockpit
2) de 881 stand alone laten draaien maar variabelen uitwisselen via netvars
3) de 881 houden en in je bijgebouw een ethernet coupler plaatsen met IO’s. Bijv de 750-362

ik denk dat optie 1 exact is wat ik zoek, mijn hoofd installatie draait dan volledig op een pcf200 en ik kan dan alles aanspreken over modbus tcp als variabelen maar mijn volledige programma is wel geschreven in e cockpit