Synchronizace výroby proudu z FV a spouštění spotřebičů

[Raww]

Bosse neznám, ale na průmyslové automatizace certifikace mám. Začal bych tím, co je mi jasné nejméně, tedy Bossem. Zda má např. nějakou možnost jednoduché vnitřní algoritmizace s reakcí na digitální vstupy (pokud je má). Případně možnost Modbus, BACnet komunikace. Záleží, co si nechá líbit. Pokud komunikaci neumí a nastavuješ to např. ve webovém rozhraní, tak to se dá robotem řešit taky.
O objevování Ameriky se asi bohužel jednat bude. To bys jedině musel oslovit nekoho od Carel, jestli už něco podobného dělali a mají na to hotové řešení.
V ideálním případě by to předpokládám nemělo hloupě zapínat/vypínat pokud je/není dostatek pro plnou zátěž, ale nějak efektivně řídit zátěž, na základě aktuálně dostupné výroby.

Hoď sem odkazy na co nejvíc dokumentací k Bossu.

Zdravim! Carel-Boss je tohle: https://www.alltyperefrigeration.com.au ... onitoring/
Myslím, že je to dost "chytré", vše se nastavuje přes web. Je tam přes modbus zapojený měřák Schneider PM5110.
Carelu (Itálie)jsem samozřejmě psal, ale zatím bez odpovědi, polský Carel nic podobného nemá.
Můžete mi napsat mail? Asi bo bude lepšé

To, že je to chytré zařízení nic nemění na tom, jak moc je "otevřené" pro "nadřazené" systémy, tj. jestli má otevřenou komunikaci s možností zápisu příkazů a parametrů. Případně alespoň programovatelné binární vstupy, kterým by šla přiřadit nějaké akce. To by bylo nejlepší.
Komunikace s analyzátorem sítě PM5110 bude nejpravděpodobněji protokolem Modbus RTU. V tomto případě se Carel ptá měřáku na síťové hodnoty a ten mu odpovídá (nejspíš kvůli řízení/optimalizaci/limitaci příkonu). Do této komunikace nic přidat nelze, protože komunikaci řídí pouze jedno zařízení na lince a to je Carel a ten čte jen to co má nadefinované výrobcem.
Odbodnou věc jsem řešil v minulosti se starou řídicí jednotkou tepelného čerpadla, které bylo úplně bez možnosti čehokoli nadřazeného - vyřešili jsme to tím, že jsme TČ sebrali jeho čidla a podvrhli jsme mu "fake" čidla tj. výstupy řídicího systému, které řídicí jednotce TČ dával vstupy, jaké jsem potřebovali a donutili jsme tak TČ poslouchat.
Dá se to udělat mnoha způsoby.

[xmasin]

Něco podobného jsem řešil pro spínání 3F bojleru, ale v podstatě je to stejná úloha. Sám jsem to vyřešil pomocí Loxonu, kdy komunikuju s měničem a dostávám data o výrobě a elektroměrem, ze kterého mám informaci o aktuální spotřebě domu. Pokud je spotřeba domu nízká a výkon dodávaný do sítě je vyšší než výkon jedné spirály, tak ji sepnu a dál kontroluji výrobu a spotřebu, pokud se zvýší spotřeba domu a začnu odebírat ze sítě tak spirálu vypnu, pokud se zvýší výroba a je znovu přetok tak připojím druhou spirálů atd. Takže pokud lze komunikovat s měničem pomocí rozumného protokolu (třeba Modbus TCP, což by Deye měly mít) a ideálně i s řídícím systémem chlazení, tak by to neměl být zas takový problém navrhnout a zprovoznit.

[gupa]

Pro zajímavost otázka, jakou má systém se spotřebou okolo půl megawaty denně kapacitu baterie ? Měniče umí nulové přetoky. Jak má taková FVE nastaveno v menu Hl. obrazovka - systémové nastavení - pracovní režim?

[cicoun]

Nejjednodušší obecné řešení je použít dry kontakt, na ten napojit relé a tím spínat zátěž. Pokud máte více spotřebičů lze je zapojit přes proudový spínač, tak aby se spouštěli postupně. To ale neřeší váš problém, kdy je potřeba mrazáky spustit při kritické teplotě ze sítě/ baterie. Dalo by se to vyřešit vřazením termostatu. Ale doporučil bych sofistikovanější řešení - manager který bude získávat informace jak z mrazaků, tak ze střídače a komunikovat s nimi. Pokud mají obě zařízení použitelné rozhraní, minimálně webový interface, je to pro průměrného programátora práce na 2 dny, což vás bude stát 10-15k, materiál 5k. Výhoda je, že nemusíte lézt do stávající instalace, jen připojíte krabičku s raspi.

[solexagro]

Bosse neznám, ale na průmyslové automatizace certifikace mám. Začal bych tím, co je mi jasné nejméně, tedy Bossem. Zda má např. nějakou možnost jednoduché vnitřní algoritmizace s reakcí na digitální vstupy (pokud je má). Případně možnost Modbus, BACnet komunikace. Záleží, co si nechá líbit. Pokud komunikaci neumí a nastavuješ to např. ve webovém rozhraní, tak to se dá robotem řešit taky.
O objevování Ameriky se asi bohužel jednat bude. To bys jedině musel oslovit nekoho od Carel, jestli už něco podobného dělali a mají na to hotové řešení.
V ideálním případě by to předpokládám nemělo hloupě zapínat/vypínat pokud je/není dostatek pro plnou zátěž, ale nějak efektivně řídit zátěž, na základě aktuálně dostupné výroby.

Hoď sem odkazy na co nejvíc dokumentací k Bossu.

Zdravim! Carel-Boss je tohle: https://www.alltyperefrigeration.com.au ... onitoring/
Myslím, že je to dost "chytré", vše se nastavuje přes web. Je tam přes modbus zapojený měřák Schneider PM5110.
Carelu (Itálie)jsem samozřejmě psal, ale zatím bez odpovědi, polský Carel nic podobného nemá.
Můžete mi napsat mail? Asi bo bude lepšé

To, že je to chytré zařízení nic nemění na tom, jak moc je "otevřené" pro "nadřazené" systémy, tj. jestli má otevřenou komunikaci s možností zápisu příkazů a parametrů. Případně alespoň programovatelné binární vstupy, kterým by šla přiřadit nějaké akce. To by bylo nejlepší.
Komunikace s analyzátorem sítě PM5110 bude nejpravděpodobněji protokolem Modbus RTU. V tomto případě se Carel ptá měřáku na síťové hodnoty a ten mu odpovídá (nejspíš kvůli řízení/optimalizaci/limitaci příkonu). Do této komunikace nic přidat nelze, protože komunikaci řídí pouze jedno zařízení na lince a to je Carel a ten čte jen to co má nadefinované výrobcem.
Odbodnou věc jsem řešil v minulosti se starou řídicí jednotkou tepelného čerpadla, které bylo úplně bez možnosti čehokoli nadřazeného - vyřešili jsme to tím, že jsme TČ sebrali jeho čidla a podvrhli jsme mu "fake" čidla tj. výstupy řídicího systému, které řídicí jednotce TČ dával vstupy, jaké jsem potřebovali a donutili jsme tak TČ poslouchat.
Dá se to udělat mnoha způsoby.

Tak co tedy mám udělat?

[solexagro]

Něco podobného jsem řešil pro spínání 3F bojleru, ale v podstatě je to stejná úloha. Sám jsem to vyřešil pomocí Loxonu, kdy komunikuju s měničem a dostávám data o výrobě a elektroměrem, ze kterého mám informaci o aktuální spotřebě domu. Pokud je spotřeba domu nízká a výkon dodávaný do sítě je vyšší než výkon jedné spirály, tak ji sepnu a dál kontroluji výrobu a spotřebu, pokud se zvýší spotřeba domu a začnu odebírat ze sítě tak spirálu vypnu, pokud se zvýší výroba a je znovu přetok tak připojím druhou spirálů atd. Takže pokud lze komunikovat s měničem pomocí rozumného protokolu (třeba Modbus TCP, což by Deye měly mít) a ideálně i s řídícím systémem chlazení, tak by to neměl být zas takový problém navrhnout a zprovoznit.

Ten Loxon jsem taky našel, napsal jsem jim, uvidíme co odpoví.
To co popisujete v v podstatě podobné ve větším..

[Raww]

Tak co tedy mám udělat?

Jak psali předchozí - sehnat co nejvíc dokumentace k zařízení, které máte. Zkusil bych se domluvit i s technikem od mrazáků na spolupráci, přeci jenom by toho měl vědět nejvíc.
Následně se domluvit s někým, kdo bude ochotný se toho ujmout, aby přijel a konkrétní věci prošel a ověřil, případně si sebou hned vzal PLC k nějakým rychlým jednoduchým zkouškám.
No a když testy klapnou, tak se pustit do seriózní realizace, aby to nebyl bastl.

[solexagro]

Nejjednodušší obecné řešení je použít dry kontakt, na ten napojit relé a tím spínat zátěž. Pokud máte více spotřebičů lze je zapojit přes proudový spínač, tak aby se spouštěli postupně. To ale neřeší váš problém, kdy je potřeba mrazáky spustit při kritické teplotě ze sítě/ baterie. Dalo by se to vyřešit vřazením termostatu. Ale doporučil bych sofistikovanější řešení - manager který bude získávat informace jak z mrazaků, tak ze střídače a komunikovat s nimi. Pokud mají obě zařízení použitelné rozhraní, minimálně webový interface, je to pro průměrného programátora práce na 2 dny, což vás bude stát 10-15k, materiál 5k. Výhoda je, že nemusíte lézt do stávající instalace, jen připojíte krabičku s raspi.

Zdravím! Toto se mi líbí. Webové rozhraní to všechno umí, každá komora má svůj kontroler a snímač teploty, můžu si je nastavit jak chci.
Jen to chce toho programátora ) Sem s ním)

[cipis]

To si zadej do toho bazaru, jako poptávku! Už jsem to psal jednou ...
Pokud se řešení problémů dostane do této roviny, nemá to pro komunitu žádný přínos, tak alespoň poslouží jako případné najití někoho, kdo z toho bude mít kšeft.

[solexagro]

Cipis: viewforum.php?f=89

S tím bazarem to nechápu, tady je taková rubrika?

[Raww]

Posílám SZ

[smartyn34]

Zdravím,
Z těch málo informací se nic konkrétně poradit nedá, jen si nenechte poradit nějaký Home assistant nebo něco podobného, to je dobré na doma si s tím hrát, ale vy potřebujete robustní systém. Např. nějaké průmyslové PLC, přeci jen by to mělo řídit tok energie za nemalé.penize.
Každopádně by to chtělo obhlídku systému a zjištění možností. Možná kdyby jste napsal odkud přibližně jste?

[cicoun]

Zdravím,
Z těch málo informací se nic konkrétně poradit nedá, jen si nenechte poradit nějaký Home assistant nebo něco podobného, to je dobré na doma si s tím hrát, ale vy potřebujete robustní systém. Např. nějaké průmyslové PLC, přeci jen by to mělo řídit tok energie za nemalé.penize.
Každopádně by to chtělo obhlídku systému a zjištění možností. Možná kdyby jste napsal odkud přibližně jste?

Většina moderních zařízení má dnes API přes http. Funguje to spolehlivě. Není potřeba nic drátovat. Home asistent není špatný, ale není určený k monitoringu a managementu - spíše ke změnám stavů a nastavení. Raspi controler Vás přijde na 2000, můžete tam mít logování, webový interface, wifi, obrazovku, integrace pomocí modbus a I/O je prakticky stejná, ale má více možností. Průmyslové PLC je dnes většinou raspi schované v krabičce se svorkami za přehnané peníze.

[unicast]

Většina moderních zařízení má dnes API přes http. Funguje to spolehlivě.

Akorát to má obrovskou hromadu zbytečného overheadu. Navíc specifikace HTTP se trvale mění (1.0 je trochu jiná než 0.9, 2.0 je hodně jiná než 1.0, 3.0 je úplně jiná než 2.0), objevují se v tom nové vektory útoků atd. atd. HTTP jinde než u šíření human readable informací je zlo.

[Mex]

Home asistent není špatný...

Souhlas.
Tahle aplikace není řízení raketoplánu ani jaderné ponorky.
Bezpečnostní mechanismy musí mít řešené už ten stávající systém řízení. Tady dostane jen dodatečnou informaci, že zrovna teď je výhodné mrazit nebo naopak že teď raději ne.

HTTP jinde než u šíření human readable informací je zlo.

Souhlas.
Ale kvůli pohodlnosti tvůrců různých systému je to bohužel často jediná možnost.

[cicoun]

Ano, právě proto jsou tam ty verze. HTTP 1.1 je stejná od roku 1997 do dnes a vsatím co chete, že bude fungovat i za 20 let. Overhetu například na REST api je minimum, xml, json apod je jiná story, ale zase nabízejí takový konfort ve zpracování požadavků, že to prostě jinak neuděláte. HTTP Rest umí i arduino nano a v pohodě ho uběhá. Kde není přístup, tam není útok. To že má každý vystrčené tepelko, solár, kamery apod. ven a ani neví přes jaký cloud server to běží je samozřejmě peklo, ale to nesouvicí s nějakou integrací přes tcp/ip v uzavřené síti.

[unicast]

Proč bych neudělal? V čem je problém s vyčítáním counterů pomocí SNMP nebo třeba YANG?

[cicoun]

SNP je nadstavba nad UDP, stejně jako HTTP je nadstavba nad TCP. Pro komunikaci s chytrými zařízeními, které mají nějaké API nad TCP to rozhodně upřednostním, čistě ze zkušenosti (to by bylo na dlouho). YANG je XML struktura přes HTTPS, to patří spíš do kategorie, proti které se stavíte.

[skybor]

Průmyslové PLC je dnes většinou raspi schované v krabičce se svorkami za přehnané peníze.

Tohle je hodně odvážné tvrzení

[cicoun]

Raspberry Pi má stejný ARM processor jako většina lepších PLC. Základ je prakticky to samé. Raspi má samozřejmě Wifi, Ethernet, HDMI, USB a podobné maličkosti. PLC moduly zase mají navíc relátka, transistory, různé rozsahy vstupů a výstupů apod. Raspi stojí 1000, při přidání nějakého rozšíření za další 1000 PLC nahradí. PLC je často uvnitř opravdu jen raspi s nějakým rozšířením a samozřejmě vlastním OS, který to zabije