Home Assistant monitoring FVE a domácnosti, návod pre úplných začiatočníkov

[mrazik]

Ještě jsem si uvědomil, že jsem zapomněl zmínit instalaci modulu socket (pip install socket resp. pip3 install socket)
Nicméně koukám na proměnné a ty vypadají v pořádku (host_moxa, port_moxa).
Moxa je nastavená v modu TCP Client ?

[xmasin]

Zkouším Home Assistant s Shelly a měničem Deye a potřeboval bych trochu nakopnout jak mám udělat automatizaci vytěžování přebytků. Z měniče vyčítám údaje pomocí integrace Solarman a chtěl bych, aby se postupně připojovaly spotřebiče podle toho jaký je přetok do DS v okamžiku když je baterie nabitá na 95%. Jako palič přebytků je bojler (2,2 kW) a 3 kW patrona v akumulační nádrži spínaná po 1 kW.

[drcvach]

Ještě jsem si uvědomil, že jsem zapomněl zmínit instalaci modulu socket (pip install socket resp. pip3 install socket)
Nicméně koukám na proměnné a ty vypadají v pořádku (host_moxa, port_moxa).
Moxa je nastavená v modu TCP Client ?

Ano, MOXA je na Portu 1 na adrese 192.168.4.34, TCP Client Mode
Destination address
xcom.studer-innotec:83
192.168.4.38:4001
:4001
:4001
Connection control: Startup/None

co mne ale mate je ta adresa 192.168.4.38:83 která se ukazuje v MOXE v přehledu Operating settings

2023-05-18_18h38_17.png (13.49 KiB) Zobrazeno 10938 x

když tam není v konfiguraci

2023-05-18_18h37_10.png (29.02 KiB) Zobrazeno 10938 x

uvidíme co kolegové co taky budou zkoušet jestli budu mít jediný problém já, nebo nás bude více.

BTW: nebylo by vhodné na tuto specifickou integraci založit nové vlákno? předpokládám že toho budeme řešit poměrně dost a dost pravděpodobně jsme se již dostali do dost velkého detailu?

[drcvach]

Ještě jsem si uvědomil, že jsem zapomněl zmínit instalaci modulu socket (pip install socket resp. pip3 install socket)
Nicméně koukám na proměnné a ty vypadají v pořádku (host_moxa, port_moxa).
Moxa je nastavená v modu TCP Client ?

Tak jsem se posunul, na vině byl Firewall který komunikaci tiše zabíjel.
Ale o moc dále jsem se nedostal

Kód: Vybrat vše

2023-05-19 00:02:16.315 - XcomLAN.node_manager.node_manager:N01 - INFO - NodeManager thread running...
2023-05-19 00:02:16.321 - XcomLAN.node_manager.node_manager:N01 - INFO - Searching devices in group 'DeviceType.XTENDER'...
2023-05-19 00:02:16.424 - root - ERROR - 'socket' object has no attribute 'in_waiting'
Traceback (most recent call last):
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 71, in write_frame
    self.set_rx_timeout(rx_timeout_in_seconds)  # Set time to wait for the response
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 49, in set_rx_timeout
    self._ser.timeout = seconds
AttributeError: attribute 'timeout' of '_socket.socket' objects is not writable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 202, in _run_with_exception_logging
    self._run()
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 216, in _run
    self._search_devices()
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 252, in _search_devices
    device_list = self._search_device_type(device_type, addressScanRange)
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 320, in _search_device_type
    response_frame = self._scom.write_frame(request_frame, 0.5)  # Set a short timeout during search
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 76, in write_frame
    response_frame = self._read_frame()
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 97, in _read_frame
    rx_data_size = self._ser.in_waiting  # Check how many bytes available
AttributeError: 'socket' object has no attribute 'in_waiting'

Nemůže to souviset s verzemi jak jsi psal?

[drcvach]

Ještě jsem si uvědomil, že jsem zapomněl zmínit instalaci modulu socket (pip install socket resp. pip3 install socket)
Nicméně koukám na proměnné a ty vypadají v pořádku (host_moxa, port_moxa).
Moxa je nastavená v modu TCP Client ?

Tak jsem se posunul, na vině byl Firewall který komunikaci tiše zabíjel.
Ale o moc dále jsem se nedostal

Kód: Vybrat vše

2023-05-19 00:02:16.315 - XcomLAN.node_manager.node_manager:N01 - INFO - NodeManager thread running...
2023-05-19 00:02:16.321 - XcomLAN.node_manager.node_manager:N01 - INFO - Searching devices in group 'DeviceType.XTENDER'...
2023-05-19 00:02:16.424 - root - ERROR - 'socket' object has no attribute 'in_waiting'
Traceback (most recent call last):
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 71, in write_frame
    self.set_rx_timeout(rx_timeout_in_seconds)  # Set time to wait for the response
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 49, in set_rx_timeout
    self._ser.timeout = seconds
AttributeError: attribute 'timeout' of '_socket.socket' objects is not writable
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 202, in _run_with_exception_logging
    self._run()
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 216, in _run
    self._search_devices()
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 252, in _search_devices
    device_list = self._search_device_type(device_type, addressScanRange)
  File "/home/drcvach/XcomLAN/XcomLAN/node_manager/node_manager.py", line 320, in _search_device_type
    response_frame = self._scom.write_frame(request_frame, 0.5)  # Set a short timeout during search
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 76, in write_frame
    response_frame = self._read_frame()
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 97, in _read_frame
    rx_data_size = self._ser.in_waiting  # Check how many bytes available
AttributeError: 'socket' object has no attribute 'in_waiting'

Nemůže to souviset s verzemi jak jsi psal?

tak nakonec po odstranění mnou zanesených chyb jsem to nějak rozjel.
Zatím se do logu vypisuje mnoho chyb s chybným parsingem paketů, ale na tom už se nějak dá pracovat.
Ještě jednou vřelé díky mrazíkovi.

2023-05-19_03h34_54.png (53.71 KiB) Zobrazeno 10890 x

[mrazik]

Kód: Vybrat vše

Traceback (most recent call last):
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 71, in write_frame
    self.set_rx_timeout(rx_timeout_in_seconds)  # Set time to wait for the response
  File "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py", line 49, in set_rx_timeout
    self._ser.timeout = seconds

Tuto chybu odstraníš tak, že v souboru "/home/drcvach/.local/lib/python3.10/site-packages/sino/scom/scom.py" zakomentuješ řádek 73 a 74 a přidáš self._ser.send(buffer)

Kód: Vybrat vše

                # self.set_rx_timeout(rx_timeout_in_seconds)  # Set time to wait for the response
                # self._ser.write(buffer)
                self._ser.send(buffer)

Modul socket nemá tuto vlastnost timeout a proto to způsobuje chybu.

[drcvach]

Ahoj,
ta chyba o které jsi psal opravena, bylo to jedno z těch míst které jsem při mnoha pokusech změnil a pak přepsal novou verzí nazpět
Aktuálně to opravdu sype data, jen v logu je poměrně velký error rate, ale to, jestli jsem správně pochopil, je teď vlastnost aktuální vývojové verze...
Do přílohy přikládám log, pokud by se ti podařilo do něj mrknout a případně identifikovat některé věci, které jsi u sebe již třeba odstranil, byl bych moc rád.

drcvach_XcomLAN_example.py_log.zip

(2.48 KiB) Staženo 1678 x

Zkusil jsem také zakázat na Routeru internet pro MOXA, tudíž MOXA neměla možnost posílat data na Studer portál, a data se do HA načítala dál, což je myslím také super zpráva (i když očekávaná).
P.

[JeffersM1]

Česky neumím, ale používám Google Translate. Co znamená "FVE"?

[Plazivec]

Photovoltaic power plant.

[mobilik]

Alebo fotovolticka elektráreň po Slovensky.

[JeffersM1]

Bude tato integrace schopna zapisovat do systému Studer? V některých obdobích velmi brzy ráno, ještě před východem slunce, je cena za odběr ze sítě velmi nízká nebo dokonce záporná a v těchto obdobích bych chtěl nabíjet baterii zvýšením úrovně SOC pro záložní parametr 06062.

[JeffersM1]

V repozitáři Github je implementace protokolu Xcom pro Xcom232i i Xcom-LAN. Vyzkouším to. https://github.com/zocker-160/xcom-protocol

[mobilik]

Vyčíta táto integrácia komplet všetky hodnoty zo systému studer, alebo len nejaké hodnoty?

[JeffersM1]

Ještě jsem to nezkoušel, ale věřím, že má přístup ke všem parametrům, které jsou zdokumentovány v příručce Studer SCOM. Autora tohoto protokolu se můžete zeptat v repozitáři na GitHubu.

[mobilik]

Ještě jsem to nezkoušel, ale věřím, že má přístup ke všem parametrům, které jsou zdokumentovány v příručce Studer SCOM. Autora tohoto protokolu se můžete zeptat v repozitáři na GitHubu.

Ok, vďaka za info a typ. Verím že ak to vyskúšate tak dáte vedieť.

[JeffersM1]

Vyzkoušel jsem protokol Xcom a zatím se mi podařilo přečíst všechna synoptická data, která v současné době čerpám z portálu Studer pomocí požadavků JSON v aplikaci Home Assistant. Problémy, na které jsem zatím narazil, jsou následující:

• 1) Nepodařilo se mi zapsat do parametru 6062 "SOC Level for Backup". Autor protokolu se domnívá, že by mohlo jít o problém s oprávněními. Doposud jsem nebyl schopen zapisovat do tohoto parametru ani pomocí požadavků JSON. Požádal jsem společnost Studer, aby se na to podívala.
  2) Hodnoty výkonu a energie PV VarioString, které načítám z parametrů 15010 a 15017, jsou jen polovinou skutečných hodnot, které dostávám při synoptických požadavcích na data. Domnívám se, že by to mohl být problém společnosti Studer, protože vzdálený RCC portálu také čte hodnoty, které jsou pouze na poloviční úrovni toho, co se očekává. Mám sice 2 řetězce VarioStrings, které mají každý stejný počet a velikost panelů, ale očekával bych, že parametry vrátí součet obou.
  3) Komunikace probíhá pomocí UDP místo TCP, takže při použití Xcom-protokolu nemohu být připojen k portálu Studer.
  4) Autor protokolu definoval pouze přátelské názvy pro parametry, které ho zajímaly, ale ostatní požadavky lze provést pomocí čísla parametru.
  5) Protokol nepodporuje vyžádání synoptických dat v dávce, každý datový bod musí být vyžádán jednotlivě. Neočekávám, že by to byl problém, a myslím, že rychlost odezvy bude mnohem lepší než u JSON a měla by být mnohem spolehlivější než u portálu.

To je zatím vše, co mám. Dám vám vědět, pokud dojde k dalšímu pokroku.

[JeffersM1]

Bylo dosaženo nějakého dalšího pokroku ve verzi komunikace Xcom-LAN s HA, kterou vyvíjí člen tohoto fóra? Je k dispozici ke stažení?

[mobilik]

Pre užívateľa mrázik.
Tak ako pokročil si v integrácii Studera do HA?
Čoskoro sa to bude riešiť aj u mňa, tak či je niečo nové, prípadne nejaké problémy či sú.
Celkom dlho to už prevádzkuješ, tak nejaké skúsenosti by pomohli.
Vďaka

[redcrown]

Ještě jsem si uvědomil, že jsem zapomněl zmínit instalaci modulu socket (pip install socket resp. pip3 install socket)
Nicméně koukám na proměnné a ty vypadají v pořádku (host_moxa, port_moxa).
Moxa je nastavená v modu TCP Client ?

Ahoj Mraziku,
s boží pomocí jsem jako absolutní neprogramátor v rámci jedné nocovky rozchodil tvoje skripty. Chodí to, mouchy to ale má. Přesto převeliké díky, pro mě to je zatím jediný způsob, jak načítat Studer hodnoty do HA a grafany.
Nevíte prosím někdo, jak fungují součtové hodnoty za všechny VT a XTM? V RCC to Studer má pod stejnými parametry, takže předpokládám, že si to sčítají a zobrazují jako jedno číslo přímo v RCC..., je to správná úvaha?
Neznajíc jak to funguje, zkusil jsem si vyčítat multicast_vt hodnotu

# list_of_user_infos_of_interest_for_multicast_vt = list(VARIO_TRACK_INFOS.keys()) # Succeed
list_of_user_infos_of_interest_for_multicast_vt = [11001, 11004]
což ale podle mě vrací jen hodnotu pro VT1.

grafana VT1-5.jpg (166.66 KiB) Zobrazeno 9116 x

Díky za osvětlení, jak to vlastně funguje.
Pokud se to musí sečíst ručně v sensoru, tak prosím o radu, jak by vypadal zápis. Takhle mám hodnotu jednoho VT

- name: "Power_of_the_PV_VT1"
unique_id: "Power_of_the_PV_VT1"
device_class: power
state_class: measurement
state_topic: "v1/gateway/telemetry"
unit_of_measurement: "W"
value_template: >
{% if value_json.N01['values'].VT1I11004 is defined %}
{{ (value_json.N01['values'].VT1I11004*1000) | round(0) }}
{% else %}
{{ states('sensor.Power_of_the_PV_VT1') }}
{% endif %}

Díky za pomoc.

[redcrown]

SOS Mrazíku,
s vypětím všech sil jsem to nainstaloval, a teď taková podpásovka. Po několika hodinách chodu skriptu se objeví chyba
Error - could not lock mutex!
Děje se to opakovaně, pokaždé trochu jinak dlouho od spouštění. Jednotky hodin. Teď naposledy to běželo 11 hodin. Objevuje se tam frekvence chyby po 10sec., interval dotazu na Xcom mám nastavený na 45sec. Stačí skript zastavit a spustit znovu.
Prosím o tip, jak hledat odstranění chyby.
konfigurace je RPI4, raspbian, HA v modu Supervised. RPI s HA mě tady běží už asi 2 roky, žádně jiné úpravy jsem v systému nedělal. Mám připojené dva Xcomy, jeden pro portál, druhý jsem teď připojil dedikovaný pro HA.
Díky moc za pomoc.

chyba XcomLAN.jpg (432.68 KiB) Zobrazeno 9066 x

[redcrown]

jo a ještě jsem narazil na takovou kuriozní věc. Mám 4xt, 1bsp, 5VT. Podle přiloženého výpisu to ale vypadá, jak když našel VT6. V mqtt exploreru to ale všechno vypadá dobře na 5ks. To spíš jen pro zajímavost. Jediné, co mě napadlo, jestli to není u adresy 300 nějaká multicast vlastnost.

Xcom 6xVT.jpg (421.48 KiB) Zobrazeno 9064 x

[redcrown]

SOS Mrazíku,
s vypětím všech sil jsem to nainstaloval, a teď taková podpásovka. Po několika hodinách chodu skriptu se objeví chyba
Error - could not lock mutex!
Děje se to opakovaně, pokaždé trochu jinak dlouho od spouštění. Jednotky hodin. Teď naposledy to běželo 11 hodin. Objevuje se tam frekvence chyby po 10sec., interval dotazu na Xcom mám nastavený na 45sec. Stačí skript zastavit a spustit znovu.
Prosím o tip, jak hledat odstranění chyby.
konfigurace je RPI4, raspbian, HA v modu Supervised. RPI s HA mě tady běží už asi 2 roky, žádně jiné úpravy jsem v systému nedělal. Mám připojené dva Xcomy, jeden pro portál, druhý jsem teď připojil dedikovaný pro HA.
Díky moc za pomoc.
chyba XcomLAN.jpg

To tu opravdu není nikdo, kdo by uměl kouknout do pythonu a posunout mě přes ten problém s "could not lock mutex!"?
Pls....
díky

[Kostěj]

To tu opravdu není nikdo, kdo by uměl kouknout do pythonu a posunout mě přes ten problém s "could not lock mutex!"?

Pokud se programuje s thready, používá se mutex jako zámek. Prostě je to takový pešek, který může držet jen jeden kus kódu. Pokud si ho chce vzít jiný kus kódu, musí si ho zamknout, jenže původní kód ho nevrátil, není volný, nejde zamknout. Všechno kvůli tomu, aby dva kusy kódu běžící současně si vzájemně nepřepisovaly sdílené proměnné. Obvykle je v tom chyba programátora, tady třeba neotestoval souběh dvou volání XcomLAN. Jestli je to možné, dal bych mezi jednotlivá volání nějaký sleep, nebo se před voláním vždy přesvědčil, že předchozí volání doběhlo, pokud ne, poslat mu nějaký reset. Obecně se tyhle chyby dohledávají a řeší dost blbě. V nouzi každou hodinu přestartovat? Jinou knihovnu na komunikaci?

[redcrown]

díky za reakci. Já tomu už tak dalece nehovím, by jsem fakt rád, že jsem to s boží pomocí nějak rozběhl. Je to ale zdroják, který již jiným uživatelům běží bez tohoto problému.
Jasně, restartovat jednou za čas by asi šlo.
Jinou knihovnu na komunikaci asi ano, ale zase platí třetí věta.
Uvidíme, třeba se k tomu nějak postaví Mrazík, který to nějak uvedl do života.

[redcrown]

Byl by někdo znalý pythonu ochotný mě napsat skriptík, který by můj python kód spustil a když dojde k té chybě mutex, tak aby se skript zastavil, počkal chvilku a zase se spustil? Hodně by mě to pomohlo. Předem díky.