APS ecu-r lokaal data uitlezen (projectje)

[grotegok]

smooc schreef op zaterdag 4 juli 2026 @ 07:56:
@grotegok @souris
Check even of je de laatste updates runt (>= 1.1.21). Daar zit een ntp update wat zou moeten dealen met het feit als het verschil (reboot zet de tijd op 2000-X-X) te groot is. Mocht dat niet zo zijn moet ik even verder kijken.

Omdat ik zelf geen last heb van een verbinding die verdwijnt, kan je iets meer uitleggen over je setup? Is je ECU gekoppeld via wifi of via ethernet? Wat betekent "geen verbinding meer"? Is de ECU niet bereikbaar, kan de ECU de inverters niet bereiken?

@souris
QS1As zijn technisch 1 fase en kunnen dus ook niet rapporteren over meerdere fases. Je kan je hardware matig wel hebben verdeeld, maar dat weet de ECU niet of nooit en de inverter zelf ook niet. Laten zien dat ze verdeeld zijn zou een software matig truukje zijn of ui dingetje. Wat is je doel?

@smooc
Geen verbinding heb ik met de WebGui, wel met SSH.
Als ik Date ingeef zie ik dat de tijd/datum weer op 1 jan staat. Doe ik date -s "2026-07-04 09:18:00" dan werkt de Web interface weer zoals verwacht. ECU is met een UTP aangesloten.

Ik ga nu even updaten, dank wederom!

update: ik zat al op 1.1.21 en nu naar 1.1.22 (in middels naar 1.1.23)

[grotegok]

@smooc ik zie op het dashboard dat ik de slider niet naar 880W kan zetten en deze wel bij het inverter overzicht wel juist staat 880/880. Betreft DS3

[smooc]

grotegok schreef op zaterdag 4 juli 2026 @ 09:34:
@smooc ik zie op het dashboard dat ik de slider niet naar 880W kan zetten en deze wel bij het inverter overzicht wel juist staat 880/880. Betreft DS3

[Afbeelding]

Volgens mij staat ie op 880W?

[grotegok]

smooc schreef op zaterdag 4 juli 2026 @ 10:30:
[...]

Volgens mij staat ie op 880W?

Klopt, maar de slider gaat niet naar rechts, staat een stukje voor de 880W, het lijkt dus alsof die niet op max staat.
Ik klaag niet hoor, denk geef het door. Het is iets visueels.

[ Voor 19% gewijzigd door grotegok op 04-07-2026 10:32 ]

[smooc]

Check, als je het een [ui] issue kan maken op de github pagina kan ik er naar kijken in de toekomst.

Welke versies (meervoud) van de software draai je? Dit ivm de datum bug die naar mijn weten opgelost zou moeten zijn al eerder ("opkg list" op de ecu geeft je de lijst)

[smooc]

@souris ik heb de firmware geupdated zodat je zelf kan kiezen welke fase je inverters op terug leveren. Dit is volledig in software (voor 3 fase inverters staat dit vast) en maakt voor de inverters niet uit maar misschien wel voor je monitoring.

[souris]

smooc schreef op zaterdag 4 juli 2026 @ 07:56:
@grotegok @souris
Check even of je de laatste updates runt (>= 1.1.21). Daar zit een ntp update wat zou moeten dealen met het feit als het verschil (reboot zet de tijd op 2000-X-X) te groot is. Mocht dat niet zo zijn moet ik even verder kijken.

Ik draaide verse 1.1.21.

Omdat ik zelf geen last heb van een verbinding die verdwijnt, kan je iets meer uitleggen over je setup? Is je ECU gekoppeld via wifi of via ethernet? Wat betekent "geen verbinding meer"? Is de ECU niet bereikbaar, kan de ECU de inverters niet bereiken?

De inverters blijven het gewoon doen, maar de ECU rapporteert niet meer. Als ik OpenAPS gebruik zijn alle inverters offline. Als ik de AP-Systems fw gebruik, dan is hij niet meer zichtbaar in HA. De ECU-R is via LAN verbonden.

@souris
QS1As zijn technisch 1 fase en kunnen dus ook niet rapporteren over meerdere fases. Je kan je hardware matig wel hebben verdeeld, maar dat weet de ECU niet of nooit en de inverter zelf ook niet. Laten zien dat ze verdeeld zijn zou een software matig truukje zijn of ui dingetje. Wat is je doel?

Ik zie graag het verbruik per fase. Ik weet welke inverter op welke fase zit. Als ik Openaps gebruik met een sunspec HA integratie, dan zie ik alleen het stroomverbruik van phase A.

[souris]

Een andere vraag: hoe bepaalt openaps het type inverter? De AP Systems fw houdt vol dat ik QS1's heb en openaps rapporteert QS1a's. Het is relevant vanwege het maximum continu vermogen.

[souris]

smooc schreef op zaterdag 4 juli 2026 @ 10:58:
@souris ik heb de firmware geupdated zodat je zelf kan kiezen welke fase je inverters op terug leveren. Dit is volledig in software (voor 3 fase inverters staat dit vast) en maakt voor de inverters niet uit maar misschien wel voor je monitoring.

Ik ga het proberen. Mijn problemen met de datum/tijd zijn trouwens exact zoals @grotegok het beschreef.

[souris]

smooc schreef op zaterdag 4 juli 2026 @ 10:58:
@souris ik heb de firmware geupdated zodat je zelf kan kiezen welke fase je inverters op terug leveren. Dit is volledig in software (voor 3 fase inverters staat dit vast) en maakt voor de inverters niet uit maar misschien wel voor je monitoring.

Ik heb v1.1.23 geïnstalleerd. Het instellen van de fases gaat niet lekker. Op diverse inverters springt hij meteen terug naar L1. Ik heb er een paar kunnen wijzigingen toen de inverters offline waren. Had een extra restart van S53-ecu-zb nodig om de inverters online te krijgen, maar kan nu dus de fases niet goed zetten. Niet in het dashboard en niet in het inverters scherm.

[smooc]

souris schreef op zaterdag 4 juli 2026 @ 20:01:
Een andere vraag: hoe bepaalt openaps het type inverter? De AP Systems fw houdt vol dat ik QS1's heb en openaps rapporteert QS1a's. Het is relevant vanwege het maximum continu vermogen.

De inverter rapporteert een model nummer. De QS1 en QS1a's (die volgens mij speciaal voor Europa zijn) hebben verschillende model nummers. Ik denk dat de frontend van APSystems geen verschil laat zien tussen QS1 / QS1a

[smooc]

souris schreef op zaterdag 4 juli 2026 @ 19:58:
[...]

Ik draaide verse 1.1.21.


[...]

De inverters blijven het gewoon doen, maar de ECU rapporteert niet meer. Als ik OpenAPS gebruik zijn alle inverters offline. Als ik de AP-Systems fw gebruik, dan is hij niet meer zichtbaar in HA. De ECU-R is via LAN verbonden.

Kan je dan nog wel inloggen op de ECU? Kan je checken wat de datum is op de ecu wanneer dit gebeurd? En load? En welke processen runnen?

[smooc]

souris schreef op zaterdag 4 juli 2026 @ 20:23:
[...]

Ik heb v1.1.23 geïnstalleerd. Het instellen van de fases gaat niet lekker. Op diverse inverters springt hij meteen terug naar L1. Ik heb er een paar kunnen wijzigingen toen de inverters offline waren. Had een extra restart van S53-ecu-zb nodig om de inverters online te krijgen, maar kan nu dus de fases niet goed zetten. Niet in het dashboard en niet in het inverters scherm.

Gefixt in 1.1.24.

[smooc]

smooc schreef op zondag 5 juli 2026 @ 11:01:
[...]

De inverter rapporteert een model nummer. De QS1 en QS1a's (die volgens mij speciaal voor Europa zijn) hebben verschillende model nummers. Ik denk dat de frontend van APSystems geen verschil laat zien tussen QS1 / QS1a

O ja, grid updates werken voor de QS1a's ook niet als je de stock firmware gebruikt. Het is nog al een messy gebeuren van APSystems heeft gemaakt.

[souris]

smooc schreef op zondag 5 juli 2026 @ 11:03:
[...]

Kan je dan nog wel inloggen op de ECU? Kan je checken wat de datum is op de ecu wanneer dit gebeurd? En load? En welke processen runnen?

Ik ben op een gegeven moment weer teruggegaan naar de stock firmware. Wat ik me herinner is dat met openaps, ik wel kan inloggen op de ECU-R en ook een reboot geven, maar dat een power cycle nodig is om de boel weer aan de gang te krijgen. Met als nadeel dat na een power cycle de tijd moet worden goed gezet door een "date -s ..." commando.

Ik heb toen niet naar de lopende processen gekeken, helaas.

[souris]

@smooc ik denk dat 1.1.24 nog niet gepusht is, of dat de package list nog niet ingepast is:

Package openaps-base (v1.1.21) installed in root is up to date.
Package openaps-inv-driver (v1.1.23) installed in root is up to date.
Package openaps-ecu-zb (v1.1.23) installed in root is up to date.
Package openaps-ecu-web (v1.1.23) installed in root is up to date.
Package openaps-ecu-sunspec (v1.1.23) installed in root is up to date.
Package openaps-recoveryd (v1.1.23) installed in root is up to date.
root@APS-ECU:~# 

[smooc]

souris schreef op zondag 5 juli 2026 @ 13:24:
@smooc ik denk dat 1.1.24 nog niet gepusht is, of dat de package list nog niet ingepast is:

Package openaps-base (v1.1.21) installed in root is up to date.
Package openaps-inv-driver (v1.1.23) installed in root is up to date.
Package openaps-ecu-zb (v1.1.23) installed in root is up to date.
Package openaps-ecu-web (v1.1.23) installed in root is up to date.
Package openaps-ecu-sunspec (v1.1.23) installed in root is up to date.
Package openaps-recoveryd (v1.1.23) installed in root is up to date.
root@APS-ECU:~# 

Dat is gek want op github staat ie released twee uur geleden. Heb je update gedaan? (opkg update)

[smooc]

souris schreef op zondag 5 juli 2026 @ 13:15:
[...]

Ik ben op een gegeven moment weer teruggegaan naar de stock firmware. Wat ik me herinner is dat met openaps, ik wel kan inloggen op de ECU-R en ook een reboot geven, maar dat een power cycle nodig is om de boel weer aan de gang te krijgen. Met als nadeel dat na een power cycle de tijd moet worden goed gezet door een "date -s ..." commando.

Ik heb toen niet naar de lopende processen gekeken, helaas.

Als onderdeel van de bootstrap heb ik een script gemaakt wat elk uur de datum goed zet. Check even of /etc/rcS.d/S56-ntpdate bestaat en of ie kan runnen (stop / start). Er lijkt wat verschil te bestaan in sommige deployments van de linux versie en packages.

Mocht ie een error geven op libcrypto (of andere lib) laat dan svp een "ls -la /lib" zien.

[smooc]

@souris lijkt er trouwens op dat de CDN van Github zn caches nog niet geupdate heeft. Even geduld denk ik.

[souris]

smooc schreef op zondag 5 juli 2026 @ 13:37:
[...]


Dat is gek want op github staat ie released twee uur geleden. Heb je update gedaan? (opkg update)

Ik had (uiteraard een opkg update gedaan). Nu is hij er wel.

[souris]

smooc schreef op zondag 5 juli 2026 @ 13:48:
@souris lijkt er trouwens op dat de CDN van Github zn caches nog niet geupdate heeft. Even geduld denk ik.

Fase instellen gaat nu goed.

ntpdate geeft:

ntpdate: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

ls -al /lib:

root@APS-ECU:~# ls -la /lib
total 11208
drwxr-x---    6 1001     1001          4096 Jun 27 10:54 .
drwxr-xr-x   18 root     root          4096 Apr 18  2025 ..
drwxr-x---    2 1001     1001          4096 Jan  1  2000 depmod.d
-rwxr-xr-x    1 1001     1001         97580 Jul 12  2021 ld-2.15.so
lrwxrwxrwx    1 root     root            10 Jan  1  2000 ld-linux-armhf.so.3 -> ld-2.15.so
-rw-r--r--    1 1001     1001          5640 Jul 12  2021 libBrokenLocale-2.15.so
lrwxrwxrwx    1 root     root            23 Jan  1  2000 libBrokenLocale.so.1 -> libBrokenLocale-2.15.so
-rwxr-xr-x    1 root     root         45807 Aug 29  2025 libYNtools.so
-rw-r--r--    1 1001     1001         14204 Jul 12  2021 libanl-2.15.so
lrwxrwxrwx    1 root     root            14 Jan  1  2000 libanl.so.1 -> libanl-2.15.so
lrwxrwxrwx    1 root     root            16 Jan  1  2000 libattr.so.1 -> libattr.so.1.1.0
-rw-r--r--    1 1001     1001         61269 Jul 12  2021 libattr.so.1.1.0
lrwxrwxrwx    1 root     root            17 Jan  1  2000 libblkid.so.1 -> libblkid.so.1.1.0
-rwxr-xr-x    1 1001     1001        127796 Jul 12  2021 libblkid.so.1.1.0
-rwxr-xr-x    1 1001     1001        881932 Jul 12  2021 libc-2.15.so
lrwxrwxrwx    1 root     root            12 Jan  1  2000 libc.so.6 -> libc-2.15.so
lrwxrwxrwx    1 root     root            14 Jan  1  2000 libcap.so.2 -> libcap.so.2.22
-rw-r--r--    1 1001     1001         60315 Jul 12  2021 libcap.so.2.22
-rw-r--r--    1 1001     1001        177792 Jul 12  2021 libcidn-2.15.so
lrwxrwxrwx    1 root     root            15 Jan  1  2000 libcidn.so.1 -> libcidn-2.15.so
lrwxrwxrwx    1 root     root            17 Jan  1  2000 libcom_err.so.2 -> libcom_err.so.2.1
-rwxr-xr-x    1 1001     1001          8876 Jul 12  2021 libcom_err.so.2.1
-rw-r--r--    1 1001     1001         26184 Jul 12  2021 libcrypt-2.15.so
lrwxrwxrwx    1 root     root            16 Jan  1  2000 libcrypt.so.1 -> libcrypt-2.15.so
lrwxrwxrwx    1 root     root            16 Jan  1  2000 libcrypto.so -> libcrypto.so.1.1
lrwxrwxrwx    1 root     root            27 Jun 27 10:54 libcrypto.so.1.0.0 -> /usr/lib/librcrypt.so.1.0.0
-rw-r--r--    1 root     root       2030173 Mar 21  2022 libcrypto.so.1.1
-rw-r--r--    1 1001     1001          9816 Jul 12  2021 libdl-2.15.so
lrwxrwxrwx    1 root     root            13 Jan  1  2000 libdl.so.2 -> libdl-2.15.so
lrwxrwxrwx    1 root     root            13 Jan  1  2000 libe2p.so.2 -> libe2p.so.2.3
-rwxr-xr-x    1 1001     1001         23976 Jul 12  2021 libe2p.so.2.3
lrwxrwxrwx    1 root     root            16 Jan  1  2000 libext2fs.so.2 -> libext2fs.so.2.4
-rwxr-xr-x    1 1001     1001        217544 Jul 12  2021 libext2fs.so.2.4
-rw-r--r--    1 1001     1001       1473720 Jul 12  2021 libgcc_s.so.1
-rwxr-xr-x    1 1001     1001         29027 Jul 12  2021 libiw.so.29
-rw-r--r--    1 1001     1001        398928 Jul 12  2021 libm-2.15.so
lrwxrwxrwx    1 root     root            12 Jan  1  2000 libm.so.6 -> libm-2.15.so
-rw-r--r--    1 1001     1001         13920 Jul 12  2021 libmemusage.so
lrwxrwxrwx    1 root     root            19 Jan  1  2000 libmudflap.so.0 -> libmudflap.so.0.0.0
-rwxr-xr-x    1 1001     1001         77536 Jul 12  2021 libmudflap.so.0.0.0
lrwxrwxrwx    1 root     root            21 Jan  1  2000 libmudflapth.so.0 -> libmudflapth.so.0.0.0
-rwxr-xr-x    1 1001     1001         82148 Jul 12  2021 libmudflapth.so.0.0.0
lrwxrwxrwx    1 root     root            18 Jan  1  2000 libncursesw.so.5 -> libncursesw.so.5.9
-rwxr-xr-x    1 1001     1001        154280 Jul 12  2021 libncursesw.so.5.9
-rw-r--r--    1 1001     1001         55244 Jul 12  2021 libnsl-2.15.so
lrwxrwxrwx    1 root     root            14 Jan  1  2000 libnsl.so.1 -> libnsl-2.15.so
-rw-r--r--    1 1001     1001         22392 Jul 12  2021 libnss_compat-2.15.so
lrwxrwxrwx    1 root     root            21 Jan  1  2000 libnss_compat.so.2 -> libnss_compat-2.15.so
-rw-r--r--    1 1001     1001         13948 Jul 12  2021 libnss_dns-2.15.so
lrwxrwxrwx    1 root     root            18 Jan  1  2000 libnss_dns.so.2 -> libnss_dns-2.15.so
-rw-r--r--    1 1001     1001         34756 Jul 12  2021 libnss_files-2.15.so
lrwxrwxrwx    1 root     root            20 Jan  1  2000 libnss_files.so.2 -> libnss_files-2.15.so
-rw-r--r--    1 1001     1001         13960 Jul 12  2021 libnss_hesiod-2.15.so
lrwxrwxrwx    1 root     root            21 Jan  1  2000 libnss_hesiod.so.2 -> libnss_hesiod-2.15.so
-rw-r--r--    1 1001     1001         30420 Jul 12  2021 libnss_nis-2.15.so
lrwxrwxrwx    1 root     root            18 Jan  1  2000 libnss_nis.so.2 -> libnss_nis-2.15.so
-rw-r--r--    1 1001     1001         34504 Jul 12  2021 libnss_nisplus-2.15.so
lrwxrwxrwx    1 root     root            22 Jan  1  2000 libnss_nisplus.so.2 -> libnss_nisplus-2.15.so
-rw-r--r--    1 1001     1001          5592 Jul 12  2021 libpcprofile.so
-rwxr-xr-x    1 1001     1001         67636 Jul 12  2021 libpthread-2.15.so
lrwxrwxrwx    1 root     root            18 Jan  1  2000 libpthread.so.0 -> libpthread-2.15.so
-rw-r--r--    1 1001     1001         55156 Jul 12  2021 libresolv-2.15.so
lrwxrwxrwx    1 root     root            17 Jan  1  2000 libresolv.so.2 -> libresolv-2.15.so
-rw-r--r--    1 1001     1001         22548 Jul 12  2021 librt-2.15.so
lrwxrwxrwx    1 root     root            13 Jan  1  2000 librt.so.1 -> librt-2.15.so
lrwxrwxrwx    1 root     root            19 Jan  1  2000 libsqlite3.so -> libsqlite3.so.0.8.6
lrwxrwxrwx    1 root     root            19 Jan  1  2000 libsqlite3.so.0 -> libsqlite3.so.0.8.6
-rwxr-xr-x    1 1001     1001       3622023 Jul 12  2021 libsqlite3.so.0.8.6
lrwxrwxrwx    1 root     root            12 Jan  1  2000 libss.so.2 -> libss.so.2.0
-rwxr-xr-x    1 1001     1001         18724 Jul 12  2021 libss.so.2.0
lrwxrwxrwx    1 root     root            13 Jan  1  2000 libssl.so -> libssl.so.1.1
-rw-r--r--    1 root     root        441936 Mar 21  2022 libssl.so.1.1
lrwxrwxrwx    1 root     root            19 Jan  1  2000 libstdc++.so.6 -> libstdc++.so.6.0.17
-rwxr-xr-x    1 1001     1001        620688 Jul 12  2021 libstdc++.so.6.0.17
-rw-r--r--    1 1001     1001          2453 Jul 12  2021 libstdc++.so.6.0.17-gdb.py
lrwxrwxrwx    1 root     root            15 Jan  1  2000 libtinfo.so.5 -> libtinfo.so.5.9
-rwxr-xr-x    1 1001     1001        118396 Jul 12  2021 libtinfo.so.5.9
lrwxrwxrwx    1 root     root            19 Jan  1  2000 libusb-0.1.so.4 -> libusb-0.1.so.4.4.4
-rwxr-xr-x    1 1001     1001         13372 Jul 12  2021 libusb-0.1.so.4.4.4
lrwxrwxrwx    1 root     root            19 Jan  1  2000 libusb-1.0.so.0 -> libusb-1.0.so.0.0.0
-rwxr-xr-x    1 1001     1001         43236 Jul 12  2021 libusb-1.0.so.0.0.0
-rw-r--r--    1 1001     1001          9852 Jul 12  2021 libutil-2.15.so
lrwxrwxrwx    1 root     root            15 Jan  1  2000 libutil.so.1 -> libutil-2.15.so
lrwxrwxrwx    1 root     root            16 Jan  1  2000 libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x    1 1001     1001         14332 Jul 12  2021 libuuid.so.1.3.0
drwxr-x---    2 1001     1001          4096 Jul 12  2021 modprobe.d
drwxr-x---    3 1001     1001          4096 Jan  1  2000 modules
drwxr-x---    5 1001     1001          4096 Jan  1  2000 udev

[grotegok]

souris schreef op zondag 5 juli 2026 @ 14:35:
[...]

Ik had (uiteraard een opkg update gedaan). Nu is hij er wel.

exact hetzelfde m.b.t. ntpdate

[ Voor 3% gewijzigd door grotegok op 05-07-2026 15:13 ]

[grotegok]

smooc schreef op zondag 5 juli 2026 @ 13:39:
[...]


Als onderdeel van de bootstrap heb ik een script gemaakt wat elk uur de datum goed zet. Check even of /etc/rcS.d/S56-ntpdate bestaat en of ie kan runnen (stop / start). Er lijkt wat verschil te bestaan in sommige deployments van de linux versie en packages.

Mocht ie een error geven op libcrypto (of andere lib) laat dan svp een "ls -la /lib" zien.

/etc/rcS.d/S56-ntpdate bestaat

[grotegok]

@smooc zojuist 1.1.27 erop gezet.
Hartelijk dank!
Mijn bevindingen volgen later.

[souris]

grotegok schreef op maandag 6 juli 2026 @ 06:45:
@smooc zojuist 1.1.27 erop gezet.
Hartelijk dank!
Mijn bevindingen volgen later.

Hier ook 1.1.27 erop gezet. So far so good. Dank weer!

[Bertus12]

grotegok schreef op maandag 6 juli 2026 @ 06:45:
@smooc zojuist 1.1.27 erop gezet.
Hartelijk dank!
Mijn bevindingen volgen later.

Ook hier 1.1.27 erop gezet ben benieuwd, ik zal de reboot die elke nacht werd uitgevoerd nu uitzetten.

[smooc]

@Bertus12 @souris @grotegok

Blijkbaar waren er verschillende software revisies van de basis firmware / linux distributie die op de ECUs draait. Dat zorgde ervoor dat ntpdate in mijn geval wel werkte en bij jullie niet . Ik heb een oudere distributie. Daarnaast zet de ECU op basis van de hardware clock de tijd, maar deze werkt helemaal niet.

Nu bundel ik een busybox die meer 'applets' heeft (o.a. ntpd en cron) en zet ik de datum aan begin van de boot naar iets wat ntpd kan verzetten (2000 -> nu is te groot en geeft een error). Start moment is net na de hwclock sync, zodat de tijd goed kom te staan ondanks dat de originele firmware deze verkeerd zet bij boot.

[souris]

smooc schreef op maandag 6 juli 2026 @ 10:15:
@Bertus12 @souris @grotegok

Blijkbaar waren er verschillende software revisies van de basis firmware / linux distributie die op de ECUs draait. Dat zorgde ervoor dat ntpdate in mijn geval wel werkte en bij jullie niet . Ik heb een oudere distributie. Daarnaast zet de ECU op basis van de hardware clock de tijd, maar deze werkt helemaal niet.

Nu bundel ik een busybox die meer 'applets' heeft (o.a. ntpd en cron) en zet ik de datum aan begin van de boot naar iets wat ntpd kan verzetten (2000 -> nu is te groot en geeft een error). Start moment is net na de hwclock sync, zodat de tijd goed kom te staan ondanks dat de originele firmware deze verkeerd zet bij boot.

Dank in ieder geval. Ik een powercycle gedaan en de tijd bleef nu goed. Nu kijken of de boel meerdere dagen stabiel blijft. Met de stock firmware had ik ook een nachtelijke powercycle via een Shelley ingesteld.

[souris]

@smooc Ik had zojuist weer een geval dat alle inverters offline waren. Ik kon wel ssh-en naar de ECU-R.

restart van S53-ecu-zb was niet genoeg. Het process stoppen en opnieuw opstarten hielp wel. De boel draait nu weer, zonder reboot of power cycle. Misschien kun je cron toevoegen aan opkg zodat ik het process 's nachts opnieuw kan starten?

Ik kan in HA zien dat het process gisteravond 18:00 onderuit is gegaan. Het is dus niet pas als er geen opwekking meer is.

[ Voor 15% gewijzigd door souris op 09-07-2026 07:53 ]

[grotegok]

souris schreef op donderdag 9 juli 2026 @ 07:52:
@smooc Ik had zojuist weer een geval dat alle inverters offline waren. Ik kon wel ssh-en naar de ECU-R.

restart van S53-ecu-zb was niet genoeg. Het process stoppen en opnieuw opstarten hielp wel. De boel draait nu weer, zonder reboot of power cycle. Misschien kun je cron toevoegen aan opkg zodat ik het process 's nachts opnieuw kan starten?

Ik kan in HA zien dat het process gisteravond 18:00 onderuit is gegaan. Het is dus niet pas als er geen opwekking meer is.

Exact hetzelfde hier, wilde net een update hier plaatsen

[Bertus12]

Ook bij mij valt af en toe de grafiek weg, ook de inverters geven aan offline te staan.
Datum tijd van de ECU klopt nu wel. Na de /etc/rcS.d/S53-ecu-zb stop/start draait het hier ook weer.

Aanvulling uit de /var/log/ecu-zb.log

code:

time=2026-07-09T16:16:39.948Z level=INFO msg="busmgr connected" component=ecu-zb sock=/var/run/inv-driver.sock
time=2026-07-09T16:16:46.594Z level=WARN msg="watchdog module unresponsive to 0x0D, recovering" component=ecu-zb
time=2026-07-09T16:16:46.898Z level=INFO msg="modem radio reset asserted, waiting 10s to settle" component=ecu-zb device=/dev/reset
time=2026-07-09T16:17:02.903Z level=ERROR msg="watchdog recovery failed, backing off" component=ecu-zb err="set-module-pan (pan=0x5D1C ch=16): no modem ack"
time=2026-07-09T16:20:46.594Z level=WARN msg="watchdog module unresponsive to 0x0D, recovering" component=ecu-zb
time=2026-07-09T16:20:46.897Z level=INFO msg="modem radio reset asserted, waiting 10s to settle" component=ecu-zb device=/dev/reset
time=2026-07-09T16:21:02.903Z level=ERROR msg="watchdog recovery failed, backing off" component=ecu-zb err="set-module-pan (pan=0x5D1C ch=16): no modem ack"
time=2026-07-09T16:21:39.958Z level=INFO msg="busmgr connected" component=ecu-zb sock=/var/run/inv-driver.sock
...
Loopt nog even door met dit

[ Voor 74% gewijzigd door Bertus12 op 09-07-2026 19:32 ]

[Bertus12]

Ik heb voor nu tijdelijk een cronjob aangemaakt met onderstaande:
Dit tot @smooc iets definitiefs heeft gevonden.

code:

0 1 * * * /etc/rcS.d/S53-ecu-zb stop
5 1 * * * /etc/rcS.d/S53-ecu-zb start

[grotegok]

Bertus12 schreef op zondag 12 juli 2026 @ 10:01:
Ik heb voor nu tijdelijk een cronjob aangemaakt met onderstaande:
Dit tot @smooc iets definitiefs heeft gevonden.

code:

0 1 * * * /etc/rcS.d/S53-ecu-zb stop
5 1 * * * /etc/rcS.d/S53-ecu-zb start

Mag ik je hulp vragen? crontab -e kent hij niet...

[Bertus12]

grotegok schreef op zondag 12 juli 2026 @ 19:13:
[...]

Mag ik je hulp vragen? crontab -e kent hij niet...

Was even zoeken maar ik heb het als volgt gedaan, is niet de meest elegante oplossing maar werkt ook na reboot (hoop ik) :

code:

busybox crontab -e

# In vi :
0 1 * * * /etc/rcS.d/S53-ecu-zb stop
5 1 * * * /etc/rcS.d/S53-ecu-zb start

# Check
busybox crontab -l

# Starten crond deamon
busybox crond -c /var/spool/cron/crontabs

# Check
ps | grep crond
 1691 root      0:00 busybox crond -c /var/spool/cron/crontabs
 1693 root      0:00 grep crond

# persistent maken
mkdir -p /etc/crontabs
cp /var/spool/cron/crontabs/root /etc/crontabs/root
cat /etc/crontabs/root
vi /etc/rcS.d/S60-crond

# In vi:

#!/bin/sh
mkdir -p /var/spool/cron/crontabs
cp /etc/crontabs/root /var/spool/cron/crontabs/root
busybox crond -c /var/spool/cron/crontabs

# Hierna
chmod +x /etc/rcS.d/S60-crond

# Nog controleren
ls -la /etc/rcS.d/S60-crond
cat /etc/crontabs/root

Ik heb nog geen reboot gedaan dus fingers crossed.

[grotegok]

Bertus12 schreef op donderdag 9 juli 2026 @ 19:23:
Ook bij mij valt af en toe de grafiek weg, ook de inverters geven aan offline te staan.
Datum tijd van de ECU klopt nu wel. Na de /etc/rcS.d/S53-ecu-zb stop/start draait het hier ook weer.

Aanvulling uit de /var/log/ecu-zb.log

code:

time=2026-07-09T16:16:39.948Z level=INFO msg="busmgr connected" component=ecu-zb sock=/var/run/inv-driver.sock
time=2026-07-09T16:16:46.594Z level=WARN msg="watchdog module unresponsive to 0x0D, recovering" component=ecu-zb
time=2026-07-09T16:16:46.898Z level=INFO msg="modem radio reset asserted, waiting 10s to settle" component=ecu-zb device=/dev/reset
time=2026-07-09T16:17:02.903Z level=ERROR msg="watchdog recovery failed, backing off" component=ecu-zb err="set-module-pan (pan=0x5D1C ch=16): no modem ack"
time=2026-07-09T16:20:46.594Z level=WARN msg="watchdog module unresponsive to 0x0D, recovering" component=ecu-zb
time=2026-07-09T16:20:46.897Z level=INFO msg="modem radio reset asserted, waiting 10s to settle" component=ecu-zb device=/dev/reset
time=2026-07-09T16:21:02.903Z level=ERROR msg="watchdog recovery failed, backing off" component=ecu-zb err="set-module-pan (pan=0x5D1C ch=16): no modem ack"
time=2026-07-09T16:21:39.958Z level=INFO msg="busmgr connected" component=ecu-zb sock=/var/run/inv-driver.sock
...
Loopt nog even door met dit

Hmm, loop meteen vast bij het eerste commando:

root@APS-ECU:~# busybox crontab -e

crontab: can't change directory to '/var/spool/cron/crontabs': No such file or directory

[grotegok]

grotegok schreef op maandag 13 juli 2026 @ 20:26:
[...]

Hmm, loop meteen vast bij het eerste commando:

root@APS-ECU:~# busybox crontab -e

crontab: can't change directory to '/var/spool/cron/crontabs': No such file or directory

Ik ga die dir even handmatig aanmaken

[Bertus12]

grotegok schreef op maandag 13 juli 2026 @ 20:26:
[...]

Hmm, loop meteen vast bij het eerste commando:

root@APS-ECU:~# busybox crontab -e

crontab: can't change directory to '/var/spool/cron/crontabs': No such file or directory

Oei ja ik zie dat de volgorde verkeerd staat, deze regel had bovenaan moeten staan

mkdir -p /var/spool/cron/crontabs

[grotegok]

ehhh wat was ook al weer het default wachtwoord? openaps dacht ik?

[grotegok]

grotegok schreef op dinsdag 8 september 2026 @ 15:07:
ehhh wat was ook al weer het default wachtwoord? openaps dacht ik?

inmiddels gelukt!

[killabee.nl]

Is er iets bekend over de tijdsplanning van OpenAPS op een raspberry pi?

Deze staat op de roadmap zag ik maar ben even benieuwd. Heb zelf geen ECU-R Pro of een ECU-C helaas.

[grotegok]

v1.1.28 is uit, werkt top

[Bertus12]

grotegok schreef op dinsdag 15 september 2026 @ 14:32:
v1.1.28 is uit, werkt top

Heb hem gelijk geïnstalleerd, draaide de laatste tijd ook al stabiel met de workaround maar dit is beter.

Weer bedankt @smooc

[verguldebarman]

grotegok schreef op dinsdag 15 september 2026 @ 14:32:
v1.1.28 is uit, werkt top

Ik heb een nieuwe ecu-r pro klaarliggen (gebruik nu nog actief en oude ecu-r) en twijfel of ik direct naar openaps overstap. Weet jij of dit gaat werken?

1. De huidige werkende ecu-r ongewijzigd offline brengen
2. Op de nieuwe ecu-r pro openaps installeren en alle inverters toevoegen
3. Vervolgens verder draaien op de ecu-r pro

Kan ik dan de ecu-r als fallback weer online brengen, mits de ecu-r pro met openaps offline is natuurlijk.....?

Tweede vraag, kan ik openaps ook in Home Assistant toevoegen?

[grotegok]

verguldebarman schreef op woensdag 16 september 2026 @ 08:34:
[...]

Ik heb een nieuwe ecu-r pro klaarliggen (gebruik nu nog actief en oude ecu-r) en twijfel of ik direct naar openaps overstap. Weet jij of dit gaat werken?

1. De huidige werkende ecu-r ongewijzigd offline brengen
2. Op de nieuwe ecu-r pro openaps installeren en alle inverters toevoegen
3. Vervolgens verder draaien op de ecu-r pro

Kan ik dan de ecu-r als fallback weer online brengen, mits de ecu-r pro met openaps offline is natuurlijk.....?

Tweede vraag, kan ik openaps ook in Home Assistant toevoegen?

Volgens mij wel, maar als de firmware niet geslikt wordt is er geen paniek.
Ja alles werkt perfect met sunspec in HA!
echt een aanrader!

[verguldebarman]

grotegok schreef op woensdag 16 september 2026 @ 15:41:
[...]

Volgens mij wel, maar als de firmware niet geslikt wordt is er geen paniek.
Ja alles werkt perfect met sunspec in HA!
echt een aanrader!

...met sunspec in HA? Ik vrees dat je dat even moet uitleggen. Ik heb nog nooit met sunspec gewerkt. 🫣🥴

[ Voor 5% gewijzigd door verguldebarman op 17-09-2026 09:15 ]

[smooc]

killabee.nl schreef op donderdag 10 september 2026 @ 08:53:
Is er iets bekend over de tijdsplanning van OpenAPS op een raspberry pi?

Deze staat op de roadmap zag ik maar ben even benieuwd. Heb zelf geen ECU-R Pro of een ECU-C helaas.

Nee op dit moment niet. Ik heb geen raspberry pi liggen die ik kan gebruiken om te testen en op dit moment vind ik ze (te) duur. Ik maak OpenAPS voor de lol.

Mocht je er een willen uitlenen / doneren dan kan ik er tijd aan besteden :-).

[smooc]

verguldebarman schreef op woensdag 16 september 2026 @ 16:26:
[...]

...met sunspec in HA? Ik vrees dat je dat even moet uitleggen. Ik heb nog nooit met sunspec gewerkt. 🫣🥴

Sunspec is de standaard op het gebied van communicatie met PV systemen. O.a. Victron ondersteunt dit (reden waarom ik OpenAPS ben gaan maken).

HA integratie kan je hier vinden: https://github.com/CJNE/ha-sunspec (er zijn misschien forks die wat bugfixes hebben trouwens, deze werkt echter gewoon).

[Bertus12]

Ik ben er inmiddels achter dat je ook met een Homey Pro de Sunspec registers via openAPS kunt uitlezen en wellicht ook kunt sturen. Je hebt hiervoor wel de Modbus app van RonnyW nodig, een APsystems ECU 2162 en natuurlijk OpenAPS van Smooc.

[Bertus12]

Eerst even een disclaimer: ik ben geen engineer, maar hobbyist. Onderstaande instellingen en resultaten zijn proefondervindelijk vastgesteld op mijn eigen installatie. Het is dus goed mogelijk dat dit bij andere configuraties anders werkt.

Zijn er hier meer gebruikers van OpenAPS, ECU-R-Pro en APsystems DS3-omvormers die hun omvormers aansturen met behulp van Homey? Ik ben benieuwd naar jullie ervaringen en bevindingen.

Het lukt mij inmiddels om de DS3-omvormers afzonderlijk te limiteren met behulp van een Homey Advanced Flow en de Modbus-app. Vanaf 2027 wil ik dit gaan gebruiken om, in combinatie met een dynamisch energiecontract, het vermogen van de omvormers automatisch te sturen.

Wat ik tot nu toe, met behulp van de OpenAPS-documentatie, AI en vooral veel testen, heb gevonden:

Per DS3-omvormer kan ik via register 40267 een waarde voor de vermogenslimiet schrijven. Vervolgens zet ik register 40271 op 1 om deze limiet actief te maken.

Bijvoorbeeld:
40267 = 8000
40271 = 1

Dit resulteert bij mijn installatie in een vermogenslimiet van ongeveer 619 W voor die omvormer.

Proefondervindelijk heb ik tot nu toe onderstaande waarden vastgesteld:

Geschreven naar 40267	Teruggelezen uit 40267	Output Cap in OpenAPS-webinterface
10000, met 40271 = 0	10000	880 W
9120	9113	706 W
9113	9090	704 W
8000	8000	619 W
7000	7000	542 W
6000	6000	465 W
5000	5000	387 W
4000	4000	310 W
3000	3000	232 W
2000	2000	155 W
1000	1000	77 W

Zijn er andere gebruikers met een DS3-omvormers en een ECU-R-Pro die hetzelfde gedrag zien en of iemand meer weet over de manier waarop register 40267 intern wordt omgerekend of begrensd.