Zie vragen en reactie op HA forum
er is iets met die nieuwe firmware die de boel verpest.
Als ik het goed begrijp is dat een response soms teveel output genereert, dat is natuurlijk killing voor resource gebruik.
Heb jij toevallig meerdere wifi access points?
Kan jij zien of hij gedurende de nacht queries doet die raar gedrag vertonen?
Kan je eventueel the service 'stop ecu query' en 'start ecu query' gebruiken. Die hadden we gemaakt om querying na zonsondergang te kunnen stoppen voor stabiliteit. Misschien helpt dat.
@adriaanh91 , jij ook weer probelemen deze dag?
Als ik het goed begrijp is dat een response soms teveel output genereert, dat is natuurlijk killing voor resource gebruik.
Heb jij toevallig meerdere wifi access points?
Kan jij zien of hij gedurende de nacht queries doet die raar gedrag vertonen?
Kan je eventueel the service 'stop ecu query' en 'start ecu query' gebruiken. Die hadden we gemaakt om querying na zonsondergang te kunnen stoppen voor stabiliteit. Misschien helpt dat.
@adriaanh91 , jij ook weer probelemen deze dag?
Ik heb geen problemen vandaag. Heb sinds gisteravond alles stabiel draaien met de gemaakte aanpassingen zoals ik deze heb doorgevoerd in de Github repo. Probleem is volgens mij dat de nieuwe firmware niet goed kan omgaan met de manier waarop de socket calls worden gedaan voor de oude firmware. Bij de nieuwe firmware wordt na elke call de connectie met de socket weer gesloten alvorens een nieuwe query te doen (ik ben geen expert...). Dit heeft bij mij het probleem opgelost.
Vannacht 1x gehad dat die geen connectie kon maken, en cache data pakte, maar niets dat iets heeft gesloopt.
Ik zie niet (meer) dat er teveel output wordt gegenereerd, dat was mijn (denk/programmeer)fout.
Vannacht 1x gehad dat die geen connectie kon maken, en cache data pakte, maar niets dat iets heeft gesloopt.
Ik zie niet (meer) dat er teveel output wordt gegenereerd, dat was mijn (denk/programmeer)fout.
De ECU 2.0.x software lijkt verre van stabiel.
Heb nu volledige logging van tweakers script gemaakt:
pi@raspberry1:~$ python3 test6.py
Asking for UID numbers and data: 19
b'APS110018000201END\n'
b'415053313130303138303030323031454e440a'
{
"ECU": {
"AnswerUID": "110018000201EN",
"timestamp": "'-- ::"
},
"UID1": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID2": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID3": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
.....
.....
Tot aan:
"UID17415": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID17416": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID17417": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID17418": {
"UID": "'",
"Online": false,
"Type": "Unknown"
}
}
Ook het korte tweakers script:
import socket
import struct
import binascii
import json
import datetime
from struct import unpack
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.1.15", 8899 ))
mystring ='APS1100280002<ECU ID>\n'
datasend = mystring.encode('utf-8')
s.send(datasend)
dataecu = s.recv(1024)
print (dataecu)
Geeft allen de volgende output:
b'APS110018000201END\n'
Het rare is dat de online portal wel info krijgt
Heb nu volledige logging van tweakers script gemaakt:
pi@raspberry1:~$ python3 test6.py
Asking for UID numbers and data: 19
b'APS110018000201END\n'
b'415053313130303138303030323031454e440a'
{
"ECU": {
"AnswerUID": "110018000201EN",
"timestamp": "'-- ::"
},
"UID1": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID2": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID3": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
.....
.....
Tot aan:
"UID17415": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID17416": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID17417": {
"UID": "'",
"Online": false,
"Type": "Unknown"
},
"UID17418": {
"UID": "'",
"Online": false,
"Type": "Unknown"
}
}
Ook het korte tweakers script:
import socket
import struct
import binascii
import json
import datetime
from struct import unpack
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.1.15", 8899 ))
mystring ='APS1100280002<ECU ID>\n'
datasend = mystring.encode('utf-8')
s.send(datasend)
dataecu = s.recv(1024)
print (dataecu)
Geeft allen de volgende output:
b'APS110018000201END\n'
Het rare is dat de online portal wel info krijgt

Wat een hoere ding 🤔🤣
Het verschil met ha en aps ema site, is dat ECU pushed naar ema en ha pull doet.
Technisch groot verschil.
Voor dat concept hadden we ooit proxy verzonnen wat we verder niet uitgewerkt hebben maar wel mogelijk zou zijn. Echter mis je dan wel wat dingen. De daily total moet je dan zelf gaan berekenen.
Wil er nog wel weer es energie in steken , Edwin had er al git project voor gemaakt. Zou best interessant kunnen zijn voor toekomstige shizzle
Het verschil met ha en aps ema site, is dat ECU pushed naar ema en ha pull doet.
Technisch groot verschil.
Voor dat concept hadden we ooit proxy verzonnen wat we verder niet uitgewerkt hebben maar wel mogelijk zou zijn. Echter mis je dan wel wat dingen. De daily total moet je dan zelf gaan berekenen.
Wil er nog wel weer es energie in steken , Edwin had er al git project voor gemaakt. Zou best interessant kunnen zijn voor toekomstige shizzle
Ik mis al 1 karakter in ANSWERUID, dus betekent dat het aantal UID die opgevraagd wordt, ook niet klopt en dan krijg je dit soort data.
Moet er nog eens terug in duiken en stapt voor stap terug (laten) opbouwen.
Moet er nog eens terug in duiken en stapt voor stap terug (laten) opbouwen.
Dapdodo,
Ik denk echt dat het aan mijn ECU ligt. Heb nog niet zoals andriaanh de 2.0.1 software gekregen, maar elke dag raakt hij nu van streek. Hierna kan je hem met geen enkele python script correct uitlezen. Rare is wel dat 8897 naar APS portal wel gewoon blijft functioneren. Dus intern lijkt die communicatie slag vanuit Zigbee nog wel goed te gaan. Heeft iemand wel eens het telnet account kunnen achterhalen? Netcat brute froce heeft vandaag nog niks uitgemaakt. Zal wel onhaalbare kans worden (kan base-64, SHA, MD5, etc zijn)
Ik denk echt dat het aan mijn ECU ligt. Heb nog niet zoals andriaanh de 2.0.1 software gekregen, maar elke dag raakt hij nu van streek. Hierna kan je hem met geen enkele python script correct uitlezen. Rare is wel dat 8897 naar APS portal wel gewoon blijft functioneren. Dus intern lijkt die communicatie slag vanuit Zigbee nog wel goed te gaan. Heeft iemand wel eens het telnet account kunnen achterhalen? Netcat brute froce heeft vandaag nog niks uitgemaakt. Zal wel onhaalbare kans worden (kan base-64, SHA, MD5, etc zijn)
@avanthof of is je wifi daar slecht? Door alle andere netwerken in de buurt.
Dapdodo,
Wifi is goed (S/N ratio) en kanaalkeuze. Hij was vandaag weer niet bereikbaar maar zie nu dat ie op ECU_R_PRO_2.0.1 draait. Dus even afwachten wat ie doet. Raar is dat ik HA even niet gekoppeld heb en handmatig script uitvraagt paar keer per dag. Wil even kijken qua instabiliteit of dat door HA interval komt of niet. Anders kan ik de HA interval verhogen wellicht. Als ie ook eruit klapt met 4x per dag, dan is zeker ECU aan een retourtje toe. Of APS support ticket.
Wifi is goed (S/N ratio) en kanaalkeuze. Hij was vandaag weer niet bereikbaar maar zie nu dat ie op ECU_R_PRO_2.0.1 draait. Dus even afwachten wat ie doet. Raar is dat ik HA even niet gekoppeld heb en handmatig script uitvraagt paar keer per dag. Wil even kijken qua instabiliteit of dat door HA interval komt of niet. Anders kan ik de HA interval verhogen wellicht. Als ie ook eruit klapt met 4x per dag, dan is zeker ECU aan een retourtje toe. Of APS support ticket.
zelfde doen als @dooiedodo antennes eraf halen en dan kijken of die beter doet.
WiFi antenne alleen he, niet de ZigBee 🧐
Mag ik vragen waarom? Want als ik de gegevens opvraag van de client in mijn wifi router doet deze het perfect want de router staan in dezelfde kast. De S/N kan niet beter.
Mijne stond nog geen meter van access point. Toch bleef prutsen met verbinding. Antenne eraf en sinds dien stabiel as fuck
Nou ik volg je advies even en beide eraf gehaald. Want volgens mij zij beide antennes Wifi want de Zigbee meestal binnen in.
Staat op de behuizing welke zigbee is, die gewoon laten zitten
Ik wil nu ook dit systeem in HA krijgen en heb het volgende gedaan:
Via deze github: https://github.com/ksheumaker/homeassistant-apsystems_ecur
ik zou ook nog https://github.com/bgbraga/homeassistant-apsystems kunnen proberen, maar die scraped gewoon van de website ipv uit de ecu-r als ik het goed begrijp.
Via deze github: https://github.com/ksheumaker/homeassistant-apsystems_ecur
- ik heb de ecu-r via wifi werkend
- tevens heb ik het ip-adres van de ecu-r in configuration.yaml gezet.
- de betreffende map in custom_components gezet
ik zou ook nog https://github.com/bgbraga/homeassistant-apsystems kunnen proberen, maar die scraped gewoon van de website ipv uit de ecu-r als ik het goed begrijp.
[ Voor 25% gewijzigd door Eraser127 op 05-10-2021 15:25 ]
Deze kun je voor nu laten zitten. Er zit een bug in waarbij de waarden maar 1 keer per etmaal worden gescraped. De developer geeft op dit moment geen thuis.Eraser127 schreef op dinsdag 5 oktober 2021 @ 14:18:
ik zou ook nog https://github.com/bgbraga/homeassistant-apsystems kunnen proberen, maar die scraped gewoon van de website ipv uit de ecu-r als ik het goed begrijp.
Wat staat er in je logfile na een ha restart?Eraser127 schreef op dinsdag 5 oktober 2021 @ 14:18:
Ik wil nu ook dit systeem in HA krijgen en heb het volgende gedaan:
Via deze github: https://github.com/ksheumaker/homeassistant-apsystems_ecurNa een reboot zie ik bij entiteiten alleen een "device_tracker.esp_8f21a3" (welke wel mijn ecu-r is) die via mijn Unifi AP verbonden is. Wat gaat er hier mis?
- ik heb de ecu-r via wifi werkend
- tevens heb ik het ip-adres van de ecu-r in configuration.yaml gezet.
- de betreffende map in custom_components gezet
ik zou ook nog https://github.com/bgbraga/homeassistant-apsystems kunnen proberen, maar die scraped gewoon van de website ipv uit de ecu-r als ik het goed begrijp.
Zover ik kan zien staat er in de logfile alleen de melding dat deze custom-component (net als unifi enz) niet door home assistent getest is....
Het werkt nu, in mijn configuration.yaml had ik staan:
ipv:
Nu zie ik alle entiteiten van de panelen/inverters
Morgen eens checken met "zon" erop.
Het werkt nu, in mijn configuration.yaml had ik staan:
code:
1
| host: [ip-adres] |
ipv:
code:
1
| host: ip-adres |

Nu zie ik alle entiteiten van de panelen/inverters
[ Voor 50% gewijzigd door Eraser127 op 11-10-2021 23:19 ]
Hebben meer mensen problemen met de verbinding tussen ECU-R en Homeassistant via https://github.com/ksheumaker/homeassistant-apsystems_ecur? De verbinding naar de cloud is prima, de data komt keurig op de APsystems website aan waardoor de app wel werkt.
[ Voor 22% gewijzigd door Eraser127 op 14-10-2021 20:11 ]
bergen ellende gehad, maar nu al maanden zonder interrupties. wat is je probleem?
Krijg nu meldingen van m'n dashboard dat de entiteiten niet beschikbaar zijn.
De eerste melding in m'n log:
Wel apart, want ik kan de ecu-r gewoon pingen (via wifi ip) en deze is ook gewoon benaderbaar via de ecuapp (dus via intern opgezette AP).
Er stond een core update klaar (core-2021.10.5), deze maar geïnstalleerd, na de reboot een tijd niet gekeken. Blijkbaar werkt de ecu-r weer
De eerste melding in m'n log:
code:
1
| hoop code |
Wel apart, want ik kan de ecu-r gewoon pingen (via wifi ip) en deze is ook gewoon benaderbaar via de ecuapp (dus via intern opgezette AP).
Er stond een core update klaar (core-2021.10.5), deze maar geïnstalleerd, na de reboot een tijd niet gekeken. Blijkbaar werkt de ecu-r weer

[ Voor 84% gewijzigd door Eraser127 op 16-10-2021 23:14 ]
die unable to connect die je had, da's meestal een reboot ecur of restart ha die het weghaalt. Als je dit vaker krijg (zoals ik had), dan is er wel wat te onderzoeken. Wifi stabiliteit van ecur is niet meest geweldige.
Dat heb ik gemerkt, wel vreemd. Heb het idee dat soms de verbinding van de ecu-r naar de cloud er dan wel is, maar de verbinding naar HA niet. Deze avond brandde de cloud-led op de ecu-r wel, maar de data bleef steken rond 13:00 vanmiddag volgens de apsystems website en verbinding naar HA was helemaal weg. Nu is de cloud-verbinding er wel weer, maar HA nog niet.
idd, stel je had een interruptie op het netwerk, dan:
- cloud data wordt niet verstuurd totdat connectie weer werkt
- cloud data wordt backfilled omdat cloud responses geeft tot welke tijd er ontvangen is
- HA krijg geen connectie meer op ecu ip
- HA kan het wsl niet oplossen zonder restart ecu en/of ha.
- HA kan niet backfillen en zal het oppakken wanneer connectie weer werkt.
- cloud data wordt niet verstuurd totdat connectie weer werkt
- cloud data wordt backfilled omdat cloud responses geeft tot welke tijd er ontvangen is
- HA krijg geen connectie meer op ecu ip
- HA kan het wsl niet oplossen zonder restart ecu en/of ha.
- HA kan niet backfillen en zal het oppakken wanneer connectie weer werkt.
[ Voor 10% gewijzigd door dooiedodo op 20-10-2021 15:59 ]
Nou, ik heb de lan maar weer ff aangesloten, steeds de verbinding weg is ook niets. Misschien APSystems maar eens mailen of ze niet die verbinding ook via lan kunnen laten lopen
.
Ik heb sinds kort een ecu-r in bezit en heb deze met dag 1 verbonden met met een UTP, en deze is niet verbonden met wifi.Eraser127 schreef op dinsdag 26 oktober 2021 @ 19:38:
Nou, ik heb de lan maar weer ff aangesloten, steeds de verbinding weg is ook niets. Misschien APSystems maar eens mailen of ze niet die verbinding ook via lan kunnen laten lopen.
Mede door dit topic laat ik deze uitlezen in Home Assistant en werkt redelijk ondanks er aangegeven werd bij de script dat een wifi verbinding nodig was.
Dus uitlezen via lan werkt toch gewoon
Enigste nadeel dat 1x per dag de verbinding verloren wordt in HA en dat ik de ecu even stroomloos moet maken. (tijdstip is random)
Power cycle via HA en een klik aan/uit stopcontact?ikbenmichel schreef op zaterdag 6 november 2021 @ 23:06:
[...]
Ik heb sinds kort een ecu-r in bezit en heb deze met dag 1 verbonden met met een UTP, en deze is niet verbonden met wifi.
Mede door dit topic laat ik deze uitlezen in Home Assistant en werkt redelijk ondanks er aangegeven werd bij de script dat een wifi verbinding nodig was.
Dus uitlezen via lan werkt toch gewoon
Enigste nadeel dat 1x per dag de verbinding verloren wordt in HA en dat ik de ecu even stroomloos moet maken. (tijdstip is random)
Hmm apart, ik moet trouwens wel even terugkomen op mijn opmerking van de lan aansluiting. Ik heb de lankabel wel ingestoken, maar de verbinding loopt nog steeds via wifi. Toch lijkt het of de ecu-r nu stabieler is qua verbinding.ikbenmichel schreef op zaterdag 6 november 2021 @ 23:06:
[...]
Ik heb sinds kort een ecu-r in bezit en heb deze met dag 1 verbonden met met een UTP, en deze is niet verbonden met wifi.
Mede door dit topic laat ik deze uitlezen in Home Assistant en werkt redelijk ondanks er aangegeven werd bij de script dat een wifi verbinding nodig was.
Dus uitlezen via lan werkt toch gewoon
Enigste nadeel dat 1x per dag de verbinding verloren wordt in HA en dat ik de ecu even stroomloos moet maken. (tijdstip is random)
ik blijf erbij.. als je wifi punt niet te ver van ecu is, gewoon eens proberen die wifi antenne er af te halen. Had super veel issue met connectie, maar sinds die actie is is niet meer disconnected geweest.
Inderdaad, heb een power cycle via het stopcontact, met een vertraging van 5 min ivm een eventuele firmware update welke via ota gaat volgens de installateur.Dapdodo schreef op zondag 7 november 2021 @ 08:59:
[...]
Power cycle via HA en een klik aan/uit stopcontact?
Maar valt wel op dat er per dag ik power cycle nodig is en de tijd is willekeurig.
Ga van de week eens kijken of een power cycle elke dag om 5 uur s’ochtends iets oplevert zodat de ecu de hele dag benaderbaar blijft voor HA. werkt niet
Vandaag even voor 15:00 was de ecu niet meer benaderbaar en gisteren rond 10:00.
Er zit geen vaste tijd aan helaas
Ga het van de week eens proberendooiedodo schreef op zondag 7 november 2021 @ 17:23:
ik blijf erbij.. als je wifi punt niet te ver van ecu is, gewoon eens proberen die wifi antenne er af te halen. Had super veel issue met connectie, maar sinds die actie is is niet meer disconnected geweest.
Aangezien het direct uitlezen van de ECU wat omslachtig is, heeft iemand wel een geprobeerd een losse meter ertussen te zetten? Bijvoorbeeld de: https://shelly.cloud/prod...t-home-automation-device/
Sindskort heb ik mijn slimme meter aan HA gekoppeld, en deze registreerd mooi het verbruik en hoeveel teruggeleverd, maar geen inzicht voor het eigen verbruik van de eigen opgewekte stroom. Hoop dat hiermee voor elkaar te krijgen.
Sindskort heb ik mijn slimme meter aan HA gekoppeld, en deze registreerd mooi het verbruik en hoeveel teruggeleverd, maar geen inzicht voor het eigen verbruik van de eigen opgewekte stroom. Hoop dat hiermee voor elkaar te krijgen.
Ik deed dit voorheen via een 5 s0 meter van smartmeterdashboard op domoticz. Alleen ben er nog niet uit hoe ik dit in HA krijg. Ik ben nog een groentje in HA maar domoticz had gewoon een plugin. Net als growatt in HA dat werkte met paar muisklikken. Alleen mijn tweede set is via APS met de ECU-R aangesloten en dat ziet er nogal omslachtig uitÜberWicked schreef op dinsdag 9 november 2021 @ 17:25:
Aangezien het direct uitlezen van de ECU wat omslachtig is, heeft iemand wel een geprobeerd een losse meter ertussen te zetten? Bijvoorbeeld de: https://shelly.cloud/prod...t-home-automation-device/
Sindskort heb ik mijn slimme meter aan HA gekoppeld, en deze registreerd mooi het verbruik en hoeveel teruggeleverd, maar geen inzicht voor het eigen verbruik van de eigen opgewekte stroom. Hoop dat hiermee voor elkaar te krijgen.
Maar weet
WP Pana 5H - Solar 6m2 icm 300liter - PV 8970Wp: 27stuks Solar - Home Assistant - VW ID3 First 20” |
Ik heb mijn s0 signalen (laadpaal) en zonnepanelen via ESP32 met Esphome laten verlopen. Is simpel. De s0 GND's met elkaar verbinden en dan alle apparte s0 naar een unieke PIN op ESP board solderen. De ESP even voorzien van een configuratie en home assistant discovered hem zelf en wordt via Wifi geintegreerd. Wifi boardje kost mss 4 euro.
Voobeeld:
sensor:
- platform: pulse_counter
pin: 17
name: "Car Charger Usage"
id: carcharger
update_interval: 10s
unit_of_measurement: 'kW'
filters:
- multiply: 0.12
total:
name: "Car Charger Total"
unit_of_measurement: "kWh"
accuracy_decimals: 0
filters:
- multiply: 0.002
Voobeeld:
sensor:
- platform: pulse_counter
pin: 17
name: "Car Charger Usage"
id: carcharger
update_interval: 10s
unit_of_measurement: 'kW'
filters:
- multiply: 0.12
total:
name: "Car Charger Total"
unit_of_measurement: "kWh"
accuracy_decimals: 0
filters:
- multiply: 0.002
Ik wil hierbij graag even de personen bedanken die zo druk bezig zijn geweest met het reversen van TCP communicatie. Ik heb zojuist een kleine NodeJS module gepubliceerd die het dus mogelijk maakt om de ECU-R met NodejS uit te lezen.
NodeJS implementatie was nodig zodat de ECU-R data uitgelezen kan worden door de Athom Homey. PR staat uit om een integratie in de 'Zonnepanelen' app van Homey de ECU-R data beschikbaar te stellen.
Maar zonder jullie enthousiasme waren deze implementaties nooit gelukt, dus hierbij, daarvoor dank!
NodeJS implementatie was nodig zodat de ECU-R data uitgelezen kan worden door de Athom Homey. PR staat uit om een integratie in de 'Zonnepanelen' app van Homey de ECU-R data beschikbaar te stellen.
Maar zonder jullie enthousiasme waren deze implementaties nooit gelukt, dus hierbij, daarvoor dank!
als dat dan operationeel is, ben ik wel nieuwsgierig naar 'stabiliteit' van integratie aldaar. Zou je dat kunnen delen tegen die tijd?rkokkelk schreef op woensdag 24 november 2021 @ 22:07:
Ik wil hierbij graag even de personen bedanken die zo druk bezig zijn geweest met het reversen van TCP communicatie. Ik heb zojuist een kleine NodeJS module gepubliceerd die het dus mogelijk maakt om de ECU-R met NodejS uit te lezen.
NodeJS implementatie was nodig zodat de ECU-R data uitgelezen kan worden door de Athom Homey. PR staat uit om een integratie in de 'Zonnepanelen' app van Homey de ECU-R data beschikbaar te stellen.
Maar zonder jullie enthousiasme waren deze implementaties nooit gelukt, dus hierbij, daarvoor dank!
Let op de ECU home assistant integratie kan problemen opleveren wanneer er naar 2022.1 geupgrade wordt.
Melding:
2021-12-01 08:51:14 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'int' got invalid input 'unavailable' when rendering template '{% if states('sensor.power_production') | int >0 %} {{ states('sensor.ecu_current_power') | int - states('sensor.power_production') | int }} {% else %} {{ states('sensor.ecu_current_power') | int }} {%endif%}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
Melding:
2021-12-01 08:51:14 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'int' got invalid input 'unavailable' when rendering template '{% if states('sensor.power_production') | int >0 %} {{ states('sensor.ecu_current_power') | int - states('sensor.power_production') | int }} {% else %} {{ states('sensor.ecu_current_power') | int }} {%endif%}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
dat is toch niet integratie gerelateerd, maar een template ?
daar kan je een default definieren voor het niet beschikbaar zijn van een waarde op enig moment. Ik heb er verschillende van voorbij zien komen en opgelost.
daar kan je een default definieren voor het niet beschikbaar zijn van een waarde op enig moment. Ik heb er verschillende van voorbij zien komen en opgelost.
ok
[ Voor 127% gewijzigd door avanthof op 01-12-2021 20:35 ]
Ik heb deze op het HA forum geplaatst: int vervangen door int(0) mocht je het nog niet hebben gezien. https://community.home-as...pull/260835/440?u=haedwin
Ik heb dus net een paar APS YC1000 micro-inverters op mijn dak gelegd gekregen en ben nu aan het kijken hoe ik deze het makkelijkst kan uitlezen. Ik heb een paar vragen.
Op internet zie ik ideëen:
1) Een CC2531 Zigbee zender met een Zigbee2MQTT firmware om rechtstreeks contact te maken met de omvormers en de info middels MQTT uit te lezen.
2) Een ECU-R plaatsen, deze koppelen met de panelen en deze middels python/HA uitlezen over poort 8899.
Volgens mij is de 2e variant me de ECU-R succesvoller gebleken dan de 1e variant met de Zigbee2MQTT, maar als ik dit topic een beetje doorlees, is het nog verre van stabiel. Ook heb ik de indruk dat APS probeert te voorkomen dat je lokaal de data uitleest, omdat ze willen dat je EMA gebruikt. Er kan dus een risico zijn dat dit op een gegeven moment niet meer beschikbaar is?
Ik nijg voor optie 2 te gaan en een ECU-R aan te schaffen. Omdat dit nogal een investering is voor een hobby projectje, wil ik het volgende wel even zeker weten:
Is het mogelijk om de ECU-R te installeren en met de YC1000 omvormers te koppelen over Zigbee zonder dat je een installateurs account hebt? Ik heb de UIDs van de omvormers wel gekregen. (beginnen allemaal met 5020000). Of moet je een installateurs account hebben om de omvormers in de ECU-R toe te voegen?
Op internet zie ik ideëen:
1) Een CC2531 Zigbee zender met een Zigbee2MQTT firmware om rechtstreeks contact te maken met de omvormers en de info middels MQTT uit te lezen.
2) Een ECU-R plaatsen, deze koppelen met de panelen en deze middels python/HA uitlezen over poort 8899.
Volgens mij is de 2e variant me de ECU-R succesvoller gebleken dan de 1e variant met de Zigbee2MQTT, maar als ik dit topic een beetje doorlees, is het nog verre van stabiel. Ook heb ik de indruk dat APS probeert te voorkomen dat je lokaal de data uitleest, omdat ze willen dat je EMA gebruikt. Er kan dus een risico zijn dat dit op een gegeven moment niet meer beschikbaar is?
Ik nijg voor optie 2 te gaan en een ECU-R aan te schaffen. Omdat dit nogal een investering is voor een hobby projectje, wil ik het volgende wel even zeker weten:
Is het mogelijk om de ECU-R te installeren en met de YC1000 omvormers te koppelen over Zigbee zonder dat je een installateurs account hebt? Ik heb de UIDs van de omvormers wel gekregen. (beginnen allemaal met 5020000). Of moet je een installateurs account hebben om de omvormers in de ECU-R toe te voegen?
De actuele opbrengst van mijn Tibber Homevolt
Ja je hebt een installateurs account nodig maar nee daar heb je geen installateur voor nodig :-) Zie de stappen op https://emea.apsystems.com/nl/resources/register/ ik heb voor de zekerheid wel twee verschillende namen en emailadressen gebruikt maar werkt ook als DIY gebruiker :-)JackBol schreef op donderdag 23 december 2021 @ 09:56:
Ik heb dus net een paar APS YC1000 micro-inverters op mijn dak gelegd gekregen en ben nu aan het kijken hoe ik deze het makkelijkst kan uitlezen. Ik heb een paar vragen.
Op internet zie ik ideëen:
1) Een CC2531 Zigbee zender met een Zigbee2MQTT firmware om rechtstreeks contact te maken met de omvormers en de info middels MQTT uit te lezen.
2) Een ECU-R plaatsen, deze koppelen met de panelen en deze middels python/HA uitlezen over poort 8899.
Volgens mij is de 2e variant me de ECU-R succesvoller gebleken dan de 1e variant met de Zigbee2MQTT, maar als ik dit topic een beetje doorlees, is het nog verre van stabiel. Ook heb ik de indruk dat APS probeert te voorkomen dat je lokaal de data uitleest, omdat ze willen dat je EMA gebruikt. Er kan dus een risico zijn dat dit op een gegeven moment niet meer beschikbaar is?
Ik nijg voor optie 2 te gaan en een ECU-R aan te schaffen. Omdat dit nogal een investering is voor een hobby projectje, wil ik het volgende wel even zeker weten:
Is het mogelijk om de ECU-R te installeren en met de YC1000 omvormers te koppelen over Zigbee zonder dat je een installateurs account hebt? Ik heb de UIDs van de omvormers wel gekregen. (beginnen allemaal met 5020000). Of moet je een installateurs account hebben om de omvormers in de ECU-R toe te voegen?
Je hebt daarna twee apps nodig: De ECU app voor installatie en de EMA app voor monitoring
WP Pana 5H - Solar 6m2 icm 300liter - PV 8970Wp: 27stuks Solar - Home Assistant - VW ID3 First 20” |
Allereerst @dooiedodo (en voor degene die eraan mee hebben gewerkt) dank voor jullie werk en bij mij werkt de integratie perfect!! Ook mooi duidelijk hoe de stappen op github zijn beschreven!! Incl het wifi verhaal. Dat zie ik zelfs bij grote projecten nog wel eens anders...
Vraagje: Ik heb naast de APS ECU-R ook een Growatt hangen en deze integratie schrijft de data net iets anders weg, kunnen jullie mij op weg helpen waar ik in de fileeditor dit zou kunnen aanpassen naar dezelfde notatie waarde achter de komma?
Vraagje: Ik heb naast de APS ECU-R ook een Growatt hangen en deze integratie schrijft de data net iets anders weg, kunnen jullie mij op weg helpen waar ik in de fileeditor dit zou kunnen aanpassen naar dezelfde notatie waarde achter de komma?
/f/image/Z2LIoEn4qSfE1zV7tfYsbvQE.png?f=fotoalbum_large)
WP Pana 5H - Solar 6m2 icm 300liter - PV 8970Wp: 27stuks Solar - Home Assistant - VW ID3 First 20” |
wijziging in een andere integratie is niet iets dat ik zo kan aanwijzen.. is growatt een custom integratie? Rapporteerd growat achter de komma in eigen app?
Dank voor de informatie. Ik heb inmiddels die ECU-R binnen en werkt als een zonnetje (pun intendedErikVers schreef op donderdag 23 december 2021 @ 11:41:
[...]
Ja je hebt een installateurs account nodig maar nee daar heb je geen installateur voor nodig :-) Zie de stappen op https://emea.apsystems.com/nl/resources/register/ ik heb voor de zekerheid wel twee verschillende namen en emailadressen gebruikt maar werkt ook als DIY gebruiker :-)
Je hebt daarna twee apps nodig: De ECU app voor installatie en de EMA app voor monitoring
Account aanmaken voor EMA was ook eenvoudig in de app te doen.
De actuele opbrengst van mijn Tibber Homevolt
heej.. dat kan niet, er is geen zon ;-)
en ja, aps is niet van het 'doe maar lekker lokaal'. Zodra je ecu van internet afhaalt, stopt hij er mee. Dat zou je kunnen stubben, zodat ie denkt dat ie online is, maar veel schiet je er niet mee op. Eventueel firmware updates voor komen.
en ja, aps is niet van het 'doe maar lekker lokaal'. Zodra je ecu van internet afhaalt, stopt hij er mee. Dat zou je kunnen stubben, zodat ie denkt dat ie online is, maar veel schiet je er niet mee op. Eventueel firmware updates voor komen.
[ Voor 76% gewijzigd door dooiedodo op 24-12-2021 14:39 ]
Ik kan in HACS de apsystems_ecur en APSystems ECU-R niet vinden. Ik heb bij integration HACS appdeamon en netdeamon al aangezet. Doe ik iets verkeerd?
Als ik hem toevoeg aan custom_components krijg ik bij configuration validation een error dat hij het component niet kan vinden.
Als ik hem toevoeg aan custom_components krijg ik bij configuration validation een error dat hij het component niet kan vinden.
[ Voor 39% gewijzigd door banaliteit op 30-12-2021 19:06 ]
Ik zie deze ook niet in HACS.dooiedodo schreef op donderdag 30 december 2021 @ 22:55:
[Afbeelding]
Gewoon in de lijst, kan zo niet zeggen wat je verkeerd hebt
Gaat iets niet goed.
our greatest fear is not that we are inadequate but that we are powerful beyond measure
In het linker menu HACS selecteren, vervolgens Integraties. Er staat dan bovenin het scherm "Integraties" met rechtsboven drie puntjes boven elkaar. Klik daarop en selecteer "Aangepaste Repositories". Vervolgens kun je de URL https://github.com/ksheumaker/homeassistant-apsystems_ecur plakken en onder de categorie "Integratie" toevoegen. Zelf krijg ik dit scherm omdat ik de integratie al eens heb toegevoegd.
:strip_exif()/f/image/cMtQrX29TV9VKgPKBXL2ESE2.jpg?f=fotoalbum_large)
Ik maak al een tijdje gebruikt van de ECU_R_Pro in combinatie met HA met wisselende resultaten. Initieel discovered HA alleen de ecu_today_xxxxx entities. Na restarten van HA, discovered HA wederom de ECU maar voegt er ecu_today_xxxxx_2 (_2) aan toe. De voorgaande staan dan op unavailable. Nu worden ook de sensors (inverters) gediscovered. Als ik HA dan weer restart, dan kan het zijn dat de eerste entities weer geactiveerd worden en dan werken de inverter sensors niet meer. Heeft een van jullie dit probleem ook? Of een oplossing? Ik heb de integratie al diverse keren verwijderd (incl entities) en gecontroleerd dat deze ook verwijderd zijn uit de core.device_registry & core.entity_registry en een restart van HA voordat ik opnieuw de integratie activeer.
Het vreemde is dat de ECU-R-Pro niet in het productenlijstje staat van APSystems. Is het ook echt een fysieke ECU-R-Pro (wat staat er zoal op de achterkant van het kastje) of is het alleen de firmware? Ik ben dus zo benieuwd waar deze versie vandaan komt! Dat deze na 72 uur niet meer is uit te vragen betekent ook dat deze niet meer met de ECUapp te configureren zou zijn. Om dat te bevestigen zou je wel even de AP knop moeten drukken en met de ECUapp connecten wat mogelijk als effect heeft dat poort 8899 ook weer open komt te staan.
Overigens is het ook een optie om periodiek een reboot commando te geven. Ik heb dat eens beschreven op het HA forum, de ECU moet dan ook via ethernet zijn verbonden. Send the string “reboot” to the ethernet ip-address of the ECU on port 4540. This is quite fast and settings are retained. ECU responds with “reboot ok”
Of dit ook werkt op de ECU-R-Pro firmware weet ik niet.
Dubbele entiteiten is een vervelende eigenschap van HA. Valt veel over te lezen op het forum, mogelijk iets met autodiscovery.
Overigens is het ook een optie om periodiek een reboot commando te geven. Ik heb dat eens beschreven op het HA forum, de ECU moet dan ook via ethernet zijn verbonden. Send the string “reboot” to the ethernet ip-address of the ECU on port 4540. This is quite fast and settings are retained. ECU responds with “reboot ok”
Of dit ook werkt op de ECU-R-Pro firmware weet ik niet.
Dubbele entiteiten is een vervelende eigenschap van HA. Valt veel over te lezen op het forum, mogelijk iets met autodiscovery.
[ Voor 6% gewijzigd door Nibblebit op 07-01-2022 14:03 ]
Ben net begonnen met het uitlezen van de ECU-R-PRO.
Net een testje uitgevoerd, maar die loopt stuk.
Omdat de versie in mijn unit nu ECU_R_PRO ipv ECU_R heeft staan, schuiven de data velden op. De timezone is nu fout en heeft nu een stukje van de versie
>>> exec(open('./APSystemsECUR.py').read())
>>> ecu=APSystemsECUR('192.168.0.0')
>>> ecu.query_ecu()
Traceback (most recent call last):
File "<string>", line 215, in check_ecu_checksum
ValueError: invalid literal for int() with base 10: b''
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 165, in query_ecu
File "<string>", line 281, in process_inverter_data
File "<string>", line 219, in check_ecu_checksum
__main__.APSystemsInvalidData: Error getting checksum int from 'Inverter data' data=b''
>>> ecu.dump()
ECU : 21620****
Firmware : ECU_R_PRO_2.0.3
TZ : 012Europe
Qty of inverters : 3
Net een testje uitgevoerd, maar die loopt stuk.
Omdat de versie in mijn unit nu ECU_R_PRO ipv ECU_R heeft staan, schuiven de data velden op. De timezone is nu fout en heeft nu een stukje van de versie
>>> exec(open('./APSystemsECUR.py').read())
>>> ecu=APSystemsECUR('192.168.0.0')
>>> ecu.query_ecu()
Traceback (most recent call last):
File "<string>", line 215, in check_ecu_checksum
ValueError: invalid literal for int() with base 10: b''
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 165, in query_ecu
File "<string>", line 281, in process_inverter_data
File "<string>", line 219, in check_ecu_checksum
__main__.APSystemsInvalidData: Error getting checksum int from 'Inverter data' data=b''
>>> ecu.dump()
ECU : 21620****
Firmware : ECU_R_PRO_2.0.3
TZ : 012Europe
Qty of inverters : 3
firmware versie is dus ECU_R_PRO_2.0.3012 (18 bytes) versus ECU_R_1.2.19009 (15 byte)
@cmos6502
Je zult in APSystemsECUR.py op regel 240 het volgende moeten veranderen:
self.firmware = self.aps_str(data, 55, 15)
wordt
self.firmware = self.aps_str(data, 55, 18)
en regel 241
self.timezone = self.aps_str(data, 70, 9)
wordt
self.timezone = self.aps_str(data, 73, 9)
Klopt het dan wel? Het helpt voor de analyse als je met Packet Sender de string "APS1100160001END" stuurt naar het IP adres van je ECU op poort 8899 en de hex response door geeft. Data portion is hopelijk wel nog 95 bytes. Vervolgens even kijken hoe we dat tweaken in de integratie.
@cmos6502
Je zult in APSystemsECUR.py op regel 240 het volgende moeten veranderen:
self.firmware = self.aps_str(data, 55, 15)
wordt
self.firmware = self.aps_str(data, 55, 18)
en regel 241
self.timezone = self.aps_str(data, 70, 9)
wordt
self.timezone = self.aps_str(data, 73, 9)
Klopt het dan wel? Het helpt voor de analyse als je met Packet Sender de string "APS1100160001END" stuurt naar het IP adres van je ECU op poort 8899 en de hex response door geeft. Data portion is hopelijk wel nog 95 bytes. Vervolgens even kijken hoe we dat tweaken in de integratie.
:strip_exif()/f/image/291lNnhsKhyAVH8g0iGzp6L8.jpg?f=fotoalbum_large)
@Nibblebit Thanks. Ik heb daar inderaad wat aanpassingen gedaan. Mijn timezone is Europe/Paris. Die is dus 12 lang ipv 9 en heb ik ook aangepast.
Kreeg daarna nog steeds errors op de inverter en signal queries. Elke keer was het ontvangen bericht leeg.
Signal Query
b''
b''
b''
Traceback (most recent call last):
File "<string>", line 227, in check_ecu_checksum
ValueError: invalid literal for int() with base 10: b''
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 176, in query_ecu
File "<string>", line 312, in process_inverter_data
File "<string>", line 275, in process_signal_data
File "<string>", line 231, in check_ecu_checksum
__main__.APSystemsInvalidData: Error getting checksum int from 'Signal Query' data=b''
Ik heb toen na elke query the socket gesloten en opnieuw geopend.
Nu krijg ik ook de data van de inverters :-)
Is dit een bekend issue met de socket interactie op de ECU?
Kreeg daarna nog steeds errors op de inverter en signal queries. Elke keer was het ontvangen bericht leeg.
Signal Query
b''
b''
b''
Traceback (most recent call last):
File "<string>", line 227, in check_ecu_checksum
ValueError: invalid literal for int() with base 10: b''
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 176, in query_ecu
File "<string>", line 312, in process_inverter_data
File "<string>", line 275, in process_signal_data
File "<string>", line 231, in check_ecu_checksum
__main__.APSystemsInvalidData: Error getting checksum int from 'Signal Query' data=b''
Ik heb toen na elke query the socket gesloten en opnieuw geopend.
Nu krijg ik ook de data van de inverters :-)
Is dit een bekend issue met de socket interactie op de ECU?
en die packet sender tool ziet er erg handig uit ;-) Ga ik ook installeren...
@Nibblebit net gechecked met packet sender (ECU_ID opvragen). data portion is 113 bytes.
hexdump
41 50 53 31 32 30 31 31 32 30 30 30 31 32 31 36 32 30 30 30 30 36 37 38 35 30 31 00 00 14 6A 00 00 00 00 00 00 00 A3 20 22 01 07 21 59 40 00 03 00 00 31 30 30 31 35 45 43 55 5F 52 5F 50 52 4F 5F 32 2E 30 2E 33 30 31 32 45 75 72 6F 70 65 2F 50 61 72 69 73 80 97 1B 02 A5 A5 60 C5 A8 79 DB 4E 30 30 00 00 00 00 00 00 00 00 00 00 45 4E 44 0A
inverters opvragen = 111 bytes
inverter signal = 40 bytes
Ik ga er maar even vanuit dat de inverter data structuren niet gewijzigd zijn.
hexdump
41 50 53 31 32 30 31 31 32 30 30 30 31 32 31 36 32 30 30 30 30 36 37 38 35 30 31 00 00 14 6A 00 00 00 00 00 00 00 A3 20 22 01 07 21 59 40 00 03 00 00 31 30 30 31 35 45 43 55 5F 52 5F 50 52 4F 5F 32 2E 30 2E 33 30 31 32 45 75 72 6F 70 65 2F 50 61 72 69 73 80 97 1B 02 A5 A5 60 C5 A8 79 DB 4E 30 30 00 00 00 00 00 00 00 00 00 00 45 4E 44 0A
inverters opvragen = 111 bytes
inverter signal = 40 bytes
Ik ga er maar even vanuit dat de inverter data structuren niet gewijzigd zijn.
[ Voor 16% gewijzigd door cmos6502 op 07-01-2022 22:25 . Reden: added length van inverter packets ]
@Nibblebit Vond uitgebreide beschrijving van het ecu info bericht in onderstaande repo.
Voor het versielabel staat versie veld lengte en zelfde voor time zone.
https://github.com/HectorMalot/ecur/blob/main/ecur.go
NewECUInfo parses the ECUInfo call into a struct
Decoded explanation
---------------------
0- 2 : APS = Mark start of datastream
3- 4 : 11 = Answer notation
4- 8 : 0094 = Datalength
9-12 : 0001 = commandnumber
13-24 : 216000026497 = ECU_R nummer
25-26 : 01 = number of inverters online
27-30 : 42896 = Lifetime energy (kWh)/10
31-34 : 00 00 00 00 = LastSystemPower kW/100
35-38 : 202 = CurrentDayEnergy (/100)
39-45 : 7xd0 = LastTimeConnectEMA
46-47 : 8 = number of inverters registered
48-49 : 0 = number of inverters online
50-51 : 10 = EcuChannel
52-54 : 014 = VersionLEN => VL
55-55+VL : ECU_R_1.2.13 = Version
56+VL-57+VL : 009 = TimeZoneLen => TL
58+VL-57+VL+TL : Etc/GMT-8 = Timezone server always indicated at -8 hours
58+VL+TL-63+VL+TL : 80 97 1b 01 5d 1e = EthernetMAC
64+VL+TL-69+VL+TL : 00 00 00 00 00 00 = WirelessMAC //Shoud be but there is a bugin firmware
70+VL+TL-73+VL+TL : END\n
Voor het versielabel staat versie veld lengte en zelfde voor time zone.
https://github.com/HectorMalot/ecur/blob/main/ecur.go
NewECUInfo parses the ECUInfo call into a struct
Decoded explanation
---------------------
0- 2 : APS = Mark start of datastream
3- 4 : 11 = Answer notation
4- 8 : 0094 = Datalength
9-12 : 0001 = commandnumber
13-24 : 216000026497 = ECU_R nummer
25-26 : 01 = number of inverters online
27-30 : 42896 = Lifetime energy (kWh)/10
31-34 : 00 00 00 00 = LastSystemPower kW/100
35-38 : 202 = CurrentDayEnergy (/100)
39-45 : 7xd0 = LastTimeConnectEMA
46-47 : 8 = number of inverters registered
48-49 : 0 = number of inverters online
50-51 : 10 = EcuChannel
52-54 : 014 = VersionLEN => VL
55-55+VL : ECU_R_1.2.13 = Version
56+VL-57+VL : 009 = TimeZoneLen => TL
58+VL-57+VL+TL : Etc/GMT-8 = Timezone server always indicated at -8 hours
58+VL+TL-63+VL+TL : 80 97 1b 01 5d 1e = EthernetMAC
64+VL+TL-69+VL+TL : 00 00 00 00 00 00 = WirelessMAC //Shoud be but there is a bugin firmware
70+VL+TL-73+VL+TL : END\n
Dat zijn mooie aanvullingen van HectorMalot om het plaatje completer te maken, hij heeft zo te lezen voortgeborduurd op het werk van @dooiedodo en mij. Dank je wel voor de verwijzing.
Ik ga met de info naar https://community.home-as...nverters-data-pull/260835 om te kijken of er nog enthousiastelingen zijn die de integratie willen aanpassen/verbeteren. Ik ben op mijn GitHub https://github.com/HAEdwin/homeassistant-apsystems_ecur op dit moment samen met Kyle nog de enige trekker voor verbeteringen van de HA integratie dus als je wilt bijdragen met code of ideeën ben je van harte welkom. Voor mij werkt de integratie 100% betrouwbaar op HA met de ECU_R firmware dus dan is het doel bereikt en de lol er een beetje vanaf
Btw. het kan inderdaad geen kwaad om de poort te sluiten alleen loop je kans op port exhaustion aan de server kant. Als je outbound verkeer initieert, creëer je een random poort (dat zie je terug in Packet Sender)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/wKwNAV8veg1JfDzoLC6GVyEJ.jpg?f=user_large)
Nu zijn er 65,535-1024 poorten beschikbaar maar als je iedere minuut aan het pollen bent kun je je voorstellen dat je er na 45 dagen echt wel doorheen bent en de HA hardware moet herstarten. Vandaar dat de socket (combinatie van ip-adres en poort) wordt hergebruikt. Als nu blijkt dat de ECU er niet tegen kan dat je telkens vanuit dezelfde socket bevraagt (bij ECU_R_PRO firmware), zal gekeken moeten worden of de ECU bijvoorbeeld minder gevoelig is voor een korte range van random poorten. Eerst maar eens bedenken waarom de ECU geen data retourneert als je vanuit een en dezelfde socket communiceert. Wel een belangrijke bevinding overigens,.. dank je wel! Ik denk dat de ECUapp ook telkens de socket sluit, zou ik eens moeten checken. Betekent wel dat de ECUapp theoretisch vast zou kunnen lopen op exhaustion maar dat is onmogelijk omdat het AP van de ECU-R niet zo lang in de lucht blijft.
Ik ga met de info naar https://community.home-as...nverters-data-pull/260835 om te kijken of er nog enthousiastelingen zijn die de integratie willen aanpassen/verbeteren. Ik ben op mijn GitHub https://github.com/HAEdwin/homeassistant-apsystems_ecur op dit moment samen met Kyle nog de enige trekker voor verbeteringen van de HA integratie dus als je wilt bijdragen met code of ideeën ben je van harte welkom. Voor mij werkt de integratie 100% betrouwbaar op HA met de ECU_R firmware dus dan is het doel bereikt en de lol er een beetje vanaf
Btw. het kan inderdaad geen kwaad om de poort te sluiten alleen loop je kans op port exhaustion aan de server kant. Als je outbound verkeer initieert, creëer je een random poort (dat zie je terug in Packet Sender)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/wKwNAV8veg1JfDzoLC6GVyEJ.jpg?f=user_large)
Nu zijn er 65,535-1024 poorten beschikbaar maar als je iedere minuut aan het pollen bent kun je je voorstellen dat je er na 45 dagen echt wel doorheen bent en de HA hardware moet herstarten. Vandaar dat de socket (combinatie van ip-adres en poort) wordt hergebruikt. Als nu blijkt dat de ECU er niet tegen kan dat je telkens vanuit dezelfde socket bevraagt (bij ECU_R_PRO firmware), zal gekeken moeten worden of de ECU bijvoorbeeld minder gevoelig is voor een korte range van random poorten. Eerst maar eens bedenken waarom de ECU geen data retourneert als je vanuit een en dezelfde socket communiceert. Wel een belangrijke bevinding overigens,.. dank je wel! Ik denk dat de ECUapp ook telkens de socket sluit, zou ik eens moeten checken. Betekent wel dat de ECUapp theoretisch vast zou kunnen lopen op exhaustion maar dat is onmogelijk omdat het AP van de ECU-R niet zo lang in de lucht blijft.
[ Voor 54% gewijzigd door Nibblebit op 08-01-2022 02:21 ]
die dubbele entitieiten heb ik ook. ruimde de _2 entititeiten eerst nog wel eens op, maar nu laat ik ze staan en is een reboot geen trigger meer voor nog meer entiteiten. Maar vooral als integratie vastloopt met connecteren, is het nog wel een verassing wat ha doet. Snap de logica er verder ook niet van en heb me er in berust dat er paar _2 entiteiten zijn die geen waardes krijgen.avanthof schreef op vrijdag 7 januari 2022 @ 08:11:
Ik maak al een tijdje gebruikt van de ECU_R_Pro in combinatie met HA met wisselende resultaten. Initieel discovered HA alleen de ecu_today_xxxxx entities. Na restarten van HA, discovered HA wederom de ECU maar voegt er ecu_today_xxxxx_2 (_2) aan toe. De voorgaande staan dan op unavailable. Nu worden ook de sensors (inverters) gediscovered. Als ik HA dan weer restart, dan kan het zijn dat de eerste entities weer geactiveerd worden en dan werken de inverter sensors niet meer. Heeft een van jullie dit probleem ook? Of een oplossing? Ik heb de integratie al diverse keren verwijderd (incl entities) en gecontroleerd dat deze ook verwijderd zijn uit de core.device_registry & core.entity_registry en een restart van HA voordat ik opnieuw de integratie activeer.
Dubbele entiteiten komen bij mij voor de ECU-R integratie eigenlijk nog zelden voor, ik restart de HA bij Serverbeheer en gebruik Z-wave JS samen met Z-Wave JS to MQTT. HA is leuk maar je moet het wel goed in de gaten houden, verkeerd gemaakte configuraties leiden soms tot niet direct zichtbare rariteiten die je later pas opmerkt als je door alle configuratie opties loopt.
Zojuist de attributen qty_of_inverters en qty_of_online_inverters toegevoegd zodat die ook worden weergegeven als attributen bij ECU current power. Loopt momenteel in de acceptatie test en als dat goed gaat pas ik het aan op mijn GitHub fork. Misschien werk ik vandaag nog aan de firmware interpretatie zodat die voor de ECU-R-PRO firmware ook goed loopt. Dus alles achter Ecuchannel whatever that may be zal verschuiven.
Zojuist de attributen qty_of_inverters en qty_of_online_inverters toegevoegd zodat die ook worden weergegeven als attributen bij ECU current power. Loopt momenteel in de acceptatie test en als dat goed gaat pas ik het aan op mijn GitHub fork. Misschien werk ik vandaag nog aan de firmware interpretatie zodat die voor de ECU-R-PRO firmware ook goed loopt. Dus alles achter Ecuchannel whatever that may be zal verschuiven.
@Nibblebit Ben bezig om eea te herschrijven/structureren. Ook voor mijn eigen kennis.
vwb de sockets: Volgens socket docs is het correct dat je maar 1 keer een request kan doen op een socket. Daarna is deze niet meer bruikbaar. Derhalve moet je dus de socket closen en opnieuw openen om een nieuwe request te doen.
Ik heb daarom een aparte requestor functie gemaakt om de technische code te abstraheren.
Verder aan het spelen met python om de velden in het bericht in een bijvoorbeeld een dictionary te zetten. Just for fun.
Hen jij ook een document met de huidige bekende bericht definities voorhanden? Of staat dat ergens op een repo? dat zou wel handig zijn.
vwb de sockets: Volgens socket docs is het correct dat je maar 1 keer een request kan doen op een socket. Daarna is deze niet meer bruikbaar. Derhalve moet je dus de socket closen en opnieuw openen om een nieuwe request te doen.
Ik heb daarom een aparte requestor functie gemaakt om de technische code te abstraheren.
Verder aan het spelen met python om de velden in het bericht in een bijvoorbeeld een dictionary te zetten. Just for fun.
Hen jij ook een document met de huidige bekende bericht definities voorhanden? Of staat dat ergens op een repo? dat zou wel handig zijn.
@cmos6502 Als je wilt bijdragen aan https://github.com/ksheumaker/homeassistant-apsystems_ecur graag, dan houden we die levend en maken we daar de integratie steeds beter. Ik ben benieuwd naar jouw implementatie voor de requestor van de inverters, dan kan ik daar ook praktijk ervaring mee op doen op de "oude" ECU-R software. In de bijlagen hieronder de bijgewerkte protocol sheet (met dank aan Dennis).
:strip_exif()/f/image/tx603bTki12tTiI6Baun5S9t.jpg?f=fotoalbum_large)
:strip_exif()/f/image/tx603bTki12tTiI6Baun5S9t.jpg?f=fotoalbum_large)
:strip_exif()/f/image/JyIlXWmGu2Id5L32xVJxLSyT.jpg?f=fotoalbum_large)
[ Voor 7% gewijzigd door Nibblebit op 09-01-2022 11:32 . Reden: Tab 1 van de protocol sheet bijgewerkt ]
Aanpassingen doorgevoerd in: https://github.com/HAEdwin/homeassistant-apsystems_ecur
Morgen nog even voor de zekerheid alles nalopen en dan doe ik een pull-request. De firmware en timezone worden dan ook bij ECU-R-PRO firmware versies juist ingelezen en getoond als attribute.
Morgen nog even voor de zekerheid alles nalopen en dan doe ik een pull-request. De firmware en timezone worden dan ook bij ECU-R-PRO firmware versies juist ingelezen en getoond als attribute.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/4dkuGzua96HsSLgJOPWbtMKo.jpg?f=user_large)
Ja, het is een echt ECU_R_Pro. Hij is paar weken terug automatisch geupgrade naar de laatste versie 2.0.3016 Het is net als cmos6502 een ECU_R_EU. Article No. 209018 en Cert data 2021.2.24. De ECU App werkt nog wel gewoon en ook de interne webpagina doet het dan nog gewoon.
[ Voor 13% gewijzigd door avanthof op 10-01-2022 10:21 ]
Ik had in een eerder stadium al de bytes aangepast. Maar lijkt er op dat ik wel herhaaldelijk de sockets kan gebruiken maar spontaan of na 72 uur ineens niet meer. De HTTP portal blijft wel normaal werken. Wilde kijken of het met een query stop kan zien ok ik het kan extenden, wellicht dat het uitvragen van de ECU terwijl de inverters down zijn mss problemen oplevert.
Sinds eind vorig jaar heb ik ook inverters van APSystems, echter heb ik de nieuwe DS3 inverter (DS3-L in mijn geval) en ik wil deze ook graag toevoegen aan mijn HA. Het is me gelukt door middel van een kleine aanpassing van de code om deze uit te lezen in HA, het device id is namelijk 703.
Echter lijkt de ECU enorm instabiel en krijgt deze geen juist IP adres van mijn DHCP server. Wanneer ik de ECU handmatig een ip geef kan ik de ECU ongeveer 15min uitlezen en verliest daarna zijn internetverbinding. Is er toevallig iemand die weet hoe je deze stabiel krijgt?
Echter lijkt de ECU enorm instabiel en krijgt deze geen juist IP adres van mijn DHCP server. Wanneer ik de ECU handmatig een ip geef kan ik de ECU ongeveer 15min uitlezen en verliest daarna zijn internetverbinding. Is er toevallig iemand die weet hoe je deze stabiel krijgt?
Ongerelateerde vraag, maar waarom gebruik je niet "import APSystemsECUR.py" voor deze actie?cmos6502 schreef op vrijdag 7 januari 2022 @ 16:25:
>>> exec(open('./APSystemsECUR.py').read())
De actuele opbrengst van mijn Tibber Homevolt
703 voor de DS3-L: staat genoteerd en pas ik vanavond aan voor de integratie. Dank je wel voor het toevoegen en het bericht!Roelos89 schreef op maandag 10 januari 2022 @ 14:23:
Sinds eind vorig jaar heb ik ook inverters van APSystems, echter heb ik de nieuwe DS3 inverter (DS3-L in mijn geval) en ik wil deze ook graag toevoegen aan mijn HA. Het is me gelukt door middel van een kleine aanpassing van de code om deze uit te lezen in HA, het device id is namelijk 703.
Echter lijkt de ECU enorm instabiel en krijgt deze geen juist IP adres van mijn DHCP server. Wanneer ik de ECU handmatig een ip geef kan ik de ECU ongeveer 15min uitlezen en verliest daarna zijn internetverbinding. Is er toevallig iemand die weet hoe je deze stabiel krijgt?
Verwar je de 15 minuten niet met het tijdelijke AP van de ECU? Bij het aanzetten brengt de ECU tijdelijk een AP in de lucht om met de ECUapp op bijvoorbeeld je telefoon verbinding te kunnen leggen. Normaliter zou het voor de router en de ECU geen probleem moeten zijn als je het MAC adres van de ECU bind aan een vast IP-adres. Dat doe ik met mijn ECU-R ook.
Het andere ip adres zoeken. ECU-R heeft er bij opstarten 2, 1 voor communicatie app en 1 voor communicatie internet. Die laatste blijft open en actief.Roelos89 schreef op maandag 10 januari 2022 @ 14:23:
Sinds eind vorig jaar heb ik ook inverters van APSystems, echter heb ik de nieuwe DS3 inverter (DS3-L in mijn geval) en ik wil deze ook graag toevoegen aan mijn HA. Het is me gelukt door middel van een kleine aanpassing van de code om deze uit te lezen in HA, het device id is namelijk 703.
Echter lijkt de ECU enorm instabiel en krijgt deze geen juist IP adres van mijn DHCP server. Wanneer ik de ECU handmatig een ip geef kan ik de ECU ongeveer 15min uitlezen en verliest daarna zijn internetverbinding. Is er toevallig iemand die weet hoe je deze stabiel krijgt?
@Roelos89 Ik heb de DS3 inverter toeevoegd aan de integratie. Misschien niet helemaal efficient als het maar effectief is. De code van de integratie moet eens flink in de revisie. Anyway als je wilt testen of dit zo ook voor jou werkt binnen HA, graag! https://github.com/HAEdwin/homeassistant-apsystems_ecur
Het lijkt prima te werken. Zo te zien is dit exact de aanpassing die ik ook gedaan had om te testenNibblebit schreef op woensdag 12 januari 2022 @ 15:15:
@Roelos89 Ik heb de DS3 inverter toeevoegd aan de integratie. Misschien niet helemaal efficient als het maar effectief is. De code van de integratie moet eens flink in de revisie. Anyway als je wilt testen of dit zo ook voor jou werkt binnen HA, graag! https://github.com/HAEdwin/homeassistant-apsystems_ecur
Top! dank je wel. Inmiddels heeft Kyle de pull request verwerkt.
Ah nice, heb een offerte ontvangen met DS3 inverters. Ik zag die echter niet als supported in de Readme staan, maar dit stemt hoopvol.
Ik heb het zojuist geinstalleerd. Het werkt.dooiedodo schreef op vrijdag 31 december 2021 @ 10:20:
Misschien handmatig repo toevoegen
https://github.com/ksheumaker/homeassistant-apsystems_ecur
[Afbeelding]
Bedankt voor alle tijd en moeite die hierin is gestoken!
Ik heb hetzelfde probleem met mijn ECU met firmware versie ECU_R_Pro 2.0.3. Na 72 uur kan ik hem niet meer uitlezen. Ik heb zojuist geprobeerd "reboot" te sturen naar het ip adres van de LAN op poort 4540, echter krijg ik geen antwoord, ook lijkt er verder niets te gebeuren.avanthof schreef op vrijdag 7 januari 2022 @ 08:53:
Het lijkt er ook op dat de ECU_R_Pro 2.0.3 nog steeds problemen heeft doordat deze door HA uitgelezen wordt. Na ongeveer 72 uur is deze niet meer uit te vragen middels 8899 maar interne website werkt nog wel gewoon.
Weet toevallig iemand of de reboot ook werkt op de ECU R Pro?
@Roelos89 heb je de interval al eens op 180 gezet? Eigenlijk update de ECU de informatie slechts per 5 minuten dus een hoge query uitvraag heeft eigenlijk geen zin. Dus 300 is als interval ook niet raar om te gebruiken.
In mijn geval heb ik de scan_interval al op 300s gezet. En na 72 uur is deze niet meer bereikbaar op poort 8899.
@Nibblebit
De interval staat al op 300, maar deze interval verlengen stelt het probleem waarschijnlijk alleen uit toch?
De interval staat al op 300, maar deze interval verlengen stelt het probleem waarschijnlijk alleen uit toch?
Ik heb mijn ECU-R moeten RMA'en omdat hij dood was gegaan.
Ik heb net de nieuwe ontvangen en zie nu dat dat ook een "PRO" is.
b'......ECU_R_PRO_2.0.3012...........END\n'
Wat is het issue met die PRO firmware? Niet stabiel?
Ik heb net de nieuwe ontvangen en zie nu dat dat ook een "PRO" is.
b'......ECU_R_PRO_2.0.3012...........END\n'
Wat is het issue met die PRO firmware? Niet stabiel?
De actuele opbrengst van mijn Tibber Homevolt
Issue met de ECU-R-PRO in combinatie met de Home Assistant integratie https://github.com/ksheumaker/homeassistant-apsystems_ecur lijkt te zijn dat bij iedere aanvraag voor data de poort moet worden geopend en gesloten anders is de ECU-R-PRO na verloop van tijd voor de integratie niet meer bereikbaar. de laatste versie van de integratie voorziet hierin. Het is niet zeker dat hiermee het probleem is opgelost.
Voor de ECU-R wordt de poort geopend en na drie aanvragen (ECU, Inverters en Signaal sterkte) pas weer gesloten. Maar bovenstaande werkt tot noch toe ook prima samen met de ECU-R.
Als je wilt proberen of de integratie werkt met de ECU-R-PRO probeer dan eens in het APSystemsECUR.py bestand na iedere close port een pauze in te lassen, misschien dat dit helpt, dus als volgt de tweede regel toevoegen:
Dit is dan van toepassing bij regels: 113, 122 en doe ook maar 130
en voordat de poort weer wordt geopend de eerste regel toevoegen:
Dit is dan van toepassing voor regels: 115 en 124
Ik ben benieuwd of dat helpt, laat het weten!
Voor de ECU-R wordt de poort geopend en na drie aanvragen (ECU, Inverters en Signaal sterkte) pas weer gesloten. Maar bovenstaande werkt tot noch toe ook prima samen met de ECU-R.
Als je wilt proberen of de integratie werkt met de ECU-R-PRO probeer dan eens in het APSystemsECUR.py bestand na iedere close port een pauze in te lassen, misschien dat dit helpt, dus als volgt de tweede regel toevoegen:
code:
1
2
| self.writer.close() await self.writer.wait_closed() |
Dit is dan van toepassing bij regels: 113, 122 en doe ook maar 130
en voordat de poort weer wordt geopend de eerste regel toevoegen:
code:
1
2
| await asyncio.sleep(1) self.reader, self.writer = await asyncio.open_connection(self.ipaddr, self.port) |
Dit is dan van toepassing voor regels: 115 en 124
Ik ben benieuwd of dat helpt, laat het weten!
[ Voor 88% gewijzigd door Nibblebit op 21-01-2022 16:46 ]
@Nibblebit
Ik heb de aanpassing doorgevoerd en voor nu werkt het nog. Ik zal komende week laten weten of de ECU nog bereikbaar is.
Ik heb de aanpassing doorgevoerd en voor nu werkt het nog. Ik zal komende week laten weten of de ECU nog bereikbaar is.
Ik zit met precies het zelfde probleem en om wat makkelijker te kunnen debuggen heb ik dat ECU_R script een beetje plat geslagen zodat je het vanuit de Python REPL kan uitvoeren.Roelos89 schreef op vrijdag 21 januari 2022 @ 10:38:
@Nibblebit
Ik heb de aanpassing doorgevoerd en voor nu werkt het nog. Ik zal komende week laten weten of de ECU nog bereikbaar is.
Wellicht handig.
Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| #!/usr/bin/env python3 import socket import binascii ip = "ADDRESS HERE" sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((ip,8899)) #ECU query sock.sendall("APS1100160001END\n".encode('utf-8')) data = sock.recv(4096) results = {} results["chksum"] = int(data[5:9]) results["ecu_id"] = str(data[13:(13+12)])[2:(12+2)] results["qty_of_inverters"] = int(binascii.b2a_hex(data[(46):(46+2)]), 16) results["qty_of_online_inverters"] = int(binascii.b2a_hex(data[(48):(48+2)]), 16) results["vsl"] = int(str(data[52:(52+3)])[2:(3+2)]) results["firmware"] = str(data[55:(55+results["vsl"])])[2:(results["vsl"]+2)] results["tsl"] = int(str(data[55+results["vsl"]:(55+results["vsl"]+3)])[2:(3+2)]) results["timezone"] = str(data[58+results["vsl"]:(58+results["vsl"]+results["tsl"])])[2:(results["tsl"]+2)] results["lifetime_energy"] = int(binascii.b2a_hex(data[(27):(27+4)]), 16) results["today_energy"] = int(binascii.b2a_hex(data[(35):(35+4)]), 16) results["current_power"] = int(binascii.b2a_hex(data[(31):(31+4)]), 16) #inverter query sock.sendall(("APS1100280002"+results["ecu_id"]+"END\n").encode('utf-8')) data_iq = sock.recv(4096) #inverter signal sock.sendall(("APS1100280030"+results["ecu_id"]+"END\n").encode('utf-8')) data_is = sock.recv(4096) sock.shutdown(socket.SHUT_RDWR) sock.close() print(results) print(data_iq) print(data_is) |
De actuele opbrengst van mijn Tibber Homevolt
Voor de ECU-R-PRO / ECU-C en Home-Assistant eigenaren, hebben jullie al eens gekeken naar de Sunspec integratie via HACS? Omdat de ECU-R-Pro en ECU-C compliant zouden zijn moet dit toch ook werken? Misschien moet je het nog wel even activeren in de configuratie van de ECU. Er zijn ook modbus test applicaties via internet te vinden, kun je het los van HA proberen.
[ Voor 35% gewijzigd door Nibblebit op 24-01-2022 12:02 ]
Als ik het goed heb begrepen hoef je het alleen maar aan te zetten (Switch On) en unieke adressen te specificeren per unit. De integratie detecteert dan vanzelf de entiteiten en kun je deze aan het energie dashboard toevoegen. Maar ik zie nu op de screenshot dat dit alleen de seriële poort is die wordt nog niet door de integratie ondersteund.
Is er geen ethernet switch? Ik meende te zien dat er in HACS of op Git nog een sunspec implementatie was te vinden. Dit deel van jouw PDF link is van belang.Currenlty supports Modbus TCP connections. Modbus serial connection is planned.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/3ILj560aVkNkbjx4I5Ch243V.jpg?f=user_large)
[ Voor 26% gewijzigd door Nibblebit op 24-01-2022 16:11 ]
Ik heb het geprobeerd met een ECU_R_Pro maar geen resultaat.
Switch -> On En elke inverter een uniek adres 1 t/m 5 (5 omvormers).
Maar wie kan vertellen of uberhaupt SunSpec via TCP uitgelezen kan worden voor de ECU_R_Pro bijvoorbeeld en niet alleen RS485. Want middels nmap staat de default port tcp/502 in ieder geval niet open.
Switch -> On En elke inverter een uniek adres 1 t/m 5 (5 omvormers).
Maar wie kan vertellen of uberhaupt SunSpec via TCP uitgelezen kan worden voor de ECU_R_Pro bijvoorbeeld en niet alleen RS485. Want middels nmap staat de default port tcp/502 in ieder geval niet open.
Ik kwam ook nog deze url tegen op de interne webserver.
http://ecu_IP/index.php/configuration
Maar daar heb je een user/pw nodig.
Voorlopig lijkt Kyle's integration de beste optie. Die draait nu anderhalve dag in mijn docker HA.
http://ecu_IP/index.php/configuration
Maar daar heb je een user/pw nodig.
Voorlopig lijkt Kyle's integration de beste optie. Die draait nu anderhalve dag in mijn docker HA.
/f/image/q90YL8ttjm3vPu9CULzR4DBr.png?f=fotoalbum_large)
[ Voor 15% gewijzigd door cmos6502 op 24-01-2022 21:55 . Reden: nu goede screenshot ]
Ben ik dan enige die geen webpages kan vinden op m'n ECU ?
Alles is connectie refuse
Alles is connectie refuse
Mijn ECU luistert niet op een andere poort dan 8899, dus zou niet weten hoe ik bij die webpagina zou moeten komen.dooiedodo schreef op dinsdag 25 januari 2022 @ 08:41:
Ben ik dan enige die geen webpages kan vinden op m'n ECU ?
Alles is connectie refuse
Ik moet wel zeggen dat ik mijn ECU_R_PRO stabiel kan uitlezen elke 180 sec.
De actuele opbrengst van mijn Tibber Homevolt
Ik heb een ECU_R_PRO en kan port 23, 80, 8080, 8899 zien via nmaps. De user/password zou ik ook wel willen weten maar dan van telnet :-p.
Welke versie draai je en hoe lang heb je deze nu actief? Want ik heb een interval van 300s en na 72 uur gaat werkelijk port 8899 down. Heb je iets aangepast aan de ECUR integratie?
Welke versie draai je en hoe lang heb je deze nu actief? Want ik heb een interval van 300s en na 72 uur gaat werkelijk port 8899 down. Heb je iets aangepast aan de ECUR integratie?
ECU_R_PRO_2.0.3avanthof schreef op dinsdag 25 januari 2022 @ 09:11:
Ik heb een ECU_R_PRO en kan port 23, 80, 8080, 8899 zien via nmaps. De user/password zou ik ook wel willen weten maar dan van telnet :-p.
Welke versie draai je en hoe lang heb je deze nu actief? Want ik heb een interval van 300s en na 72 uur gaat werkelijk port 8899 down. Heb je iets aangepast aan de ECUR integratie?
Ik gebruik niet HACS, dus ik heb zelf iets in elkaar geknutseld.
Mijn primaire dataverzamelaar is telegraf. Ik heb daarom een klein python webservertje gemaakt dat de generieke data ophaalt.
Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| #!/usr/bin/env python3 from http.server import BaseHTTPRequestHandler, HTTPServer import socket import binascii import json ip = "192.168.2.14" hostName = "localhost" serverPort = 8080 def get_ECU(): # ECU query sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((ip, 8899)) sock.sendall("APS1100160001END\n".encode('utf-8')) data = sock.recv(4096) sock.shutdown(socket.SHUT_RDWR) sock.close() results = {} results["chksum"] = int(data[5:9]) results["ecu_id"] = str(data[13:(13 + 12)])[2:(12 + 2)] results["qty_of_inverters"] = int(binascii.b2a_hex(data[(46):(46 + 2)]), 16) results["qty_of_online_inverters"] = int(binascii.b2a_hex(data[(48):(48 + 2)]), 16) results["vsl"] = int(str(data[52:(52 + 3)])[2:(3 + 2)]) results["firmware"] = str(data[55:(55 + results["vsl"])])[2:(results["vsl"] + 2)] results["tsl"] = int(str(data[55 + results["vsl"]:(55 + results["vsl"] + 3)])[2:(3 + 2)]) results["timezone"] = str(data[58 + results["vsl"]:(58 + results["vsl"] + results["tsl"])])[ 2:(results["tsl"] + 2)] results["lifetime_energy"] = int(binascii.b2a_hex(data[(27):(27 + 4)]), 16) results["today_energy"] = int(binascii.b2a_hex(data[(35):(35 + 4)]), 16) results["current_power"] = int(binascii.b2a_hex(data[(31):(31 + 4)]), 16) return json.dumps(results) class MyServer(BaseHTTPRequestHandler): def do_GET(self): self.send_response(200) self.send_header("Content-type", "application/json") self.end_headers() self.wfile.write(bytes(get_ECU(), encodings="utf-8")) if __name__ == "__main__": webServer = HTTPServer((hostName, serverPort), MyServer) print("Server started http://%s:%s" % (hostName, serverPort)) while True: webServer.serve_forever() webServer.server_close() print("Server stopped.") |
De actuele opbrengst van mijn Tibber Homevolt
@JackBol Leuke oplossing! Een http wrapper om de ECU. De code kan uitgebreidt worden met inverter info (if needed). HA zou dan deze webserver kunnen aanroepen.
@JackBol Hoe heb je dan de HA integatie ingeregeld?