Hallo, ich wollte nur kurz meine Anwendung zeigen.
In der Küche habe ich die alte Wetteranzeige gegen ein altes Tablett getauscht.
Der Fully Browser misst den Füllstand und schaltet bei Bedarf die USB-Steckdose an und aus.
Neben dem Wetter und dem Müllkalender sehe ich noch den Status von Spülmaschine (Restlaufzeit), Waschmaschine&Trockner (ob AN per PowerPlug), Garagentor (aktivierbar). Auch kann ich in weitere Ansichten springen für Stockwerke, Rolläden und WLAN-Lautsprecher.
Die Views habe ich ähnlich gehalten und von den Veröffentlichungen hier zusammengetragen.
Hardware:
Tablett: 2018 Fire HD 8", fullybrowser mit Lizenz
Steckdose schaltbar: Luminea Home Control WLAN Steckdose: 2in1-WLAN (https://amzn.eu/d/6xtjV6e)
USB-Kabel: https://amzn.eu/d/f5apruB
Zentrale: RaspberryPi4 mit RPI-RF-MOD (Homematic, PivCCU)
@bilberry basierend auf https://github.com/suaveolent/hoymiles-wifi und mit Hilfe von ChatGPT und dem Studium von ein paar weiteren Seiten konnte ich einen Adapter basteln, Vor-Alpha-Status. Ich das ist nicht offiziell und ich übernehme keine Verantwortung.
Vorteil: arbeitet im LAN (ist auch schneller als die Webseite in China), Datenpunkte in ioBroker.
Instanz hinzufügen,Adaptersettings: IP-Adresse der HMS-800W-2T anpassen.
Hinweis:
a) Wenn Abfragen nicht erfolgreich (z.B. nachts hat HMS keine IP), dann ist bei Instanz "Verbunden mit Gerät oder Dienst" der Status orange statt grün, Der Objektpunkt Online will noch nicht.
b) hoymiles-wifi.0.get_real_data_new.dtuPower = 3000 entspricht 300,0 Watt. Der Punkt ist in meinen Augen der Wichtigste.
@mcm1957
Ein sehr guter genereller Warnhinweis!
Um so wichtiger, als kurz nach meiner letzen Version mein Raspberry Probleme machte, deren Eingrenzung im Try- and Errorverfahren Tage brauchte und am Ende war es aber nur das Netzteil und ein anderes Dockupdate.
Leider habe ich noch keine freiwilligen Tester und Feedbacks.
@bananajoe
BackupItUp fällt bei mir kaum auf (, ich mache per DD ein Image während ioBroker gestoppt ist). Ja, 4GB sind nicht mehr zeitgemäß. Interessanter Weise brachte es auch etwas unter 64 bit Bookworm das BackUp vom 32er Bookworm anstelle vom 32er Bullseye zu verwenden: etwa 17% mehr Verbrauch gegenüber 33% ursprünglich, bei mehreren Messungen, vielleicht auch Zufall.
Ich darf mich halt daran gewöhnen etwas vorsichter mit meinem RAM umzugehen als zuvor
Danke für die Unterstützung!
@meister-mopper
Hallo MM,
64bit Bookworm war komplett frisch installiert,
nach einer frischen Installation von piVCCU wurde auch ioBroker frisch installiert, Restore aus BackItUp aus der 32er Version Bullseye installiert.
dank div. Images konnte ich etwas hin- und herspringen und das Upgrade vom 32erBullseye auf das 32erBookworm ist noch neu; dessen neues BackUp wollte ich als nächstes fürs 64er Bookworm probieren. Aber heute schaffe ich das nicht mehr...
Ich kann mir nicht so recht erklären wie das Betriebssystem so enorm sich auf den Speicherbedarf von ioBroker auswirkt.
Kann mir das bitte jemand erklären und ggf. Wege aufzeigen das Niveau zu normalisieren? Ein leichter Zuwachs nach Updates und je nach Umgebung leuchtet noch ein, aber in diesem Ausmaß?
RAM: meist deutlich mehr als 1GB frei, bei Neustart kurzfristig 0,9GB frei – von 4 GB.
CPU-Last selten hoch, regulär <30%
Fazit: die Kiste ist definitiv nicht ausgelastet.
Unter 64bit läuft der Speicher gelegentlich voll (nach frischer Installation OS: 64bit Bookworm, piVCCU, ioBroker (Restore aus backitup, weniger gestarteten Adaptern; ohne Docker/AdAware).
Daher habe ich den Speicherbedarf der Adapter verglichen (jeweils aktuelles OS und ioBroker), 32bit Bullseye gegen 32bit Bookworm (+7% mehr RAM-Bedarf der Instanzen) gegen 64bit Bookworm (+33% mehr RAM-Bedarf der Instanzen).
@tourer4778
Ich habe das Projekt VIS-2 erstmal in den Ruhestand geschickt. Ich beobachte die Entwicklung weiter und teste die Versionen in meinem Testsystem. Für mich gibt es noch zu viele Baustellen. Ich bleibe daher bei VIS-1. Ich bin daher hier nicht weitergekommen.
dito.
Ich bin gerade dabei meinen Pi von 32bit Bullseye auf 64bit Bookworm umzustellen, div. Komponentenwie piVCCU dürfen neu eingerichtet werden. Daher auch von mir noch kein Update.
@eule01 Oh, das Problem hatte ich auch. Auf die Schnelle hatte ich das Python hoymiles-wifi als root installiert, dann wurde es auch vom ioBroker gefunden. Aber stimmt, als root sollte man sowas nicht machen, besser regulär installieren und den Pfad anpassen.
@drnicolas PING und HOYMILES-WIFI kann ich als regulärer User ausführen (Raspbian GNU/Linux 11 (bullseye)).
Und in diesem Kontext führt der Adapter die Befehle aus und verarbeitet die Antworten.
Die Option "Skip Poll" benutzt PING lediglich um zu erkennen ob das Balkonkraftwerk nachts nicht mehr erreichbar ist um sich dann die Abfrage zu sparen. Also einfach deaktivieren, funktionieren sollte es dennoch.
@novi Bei mir läuft es mit Cloud und Raspi parallel, aber du hast Recht: die Cloud wird weit seltener aktualisiert. Das hatte ich aber vorher auch schon recht verzögert, aber nie die Verzögerung gemessen.
Ich habe bei mir das Intervall auf 5 Minuten (also 300 Sekunden) angehoben. Der Abgleich mit der App/Cloud geht so wohl etwas besser, scheinbar werden die Tagesdaten über die historischen Daten von hoymiles-wifi.0.app_get_hist_power immer wieder nachgebessert - vermutlich sind die Server in der chinesischen Cloud nicht besonders performant.
hoymiles-wifi.0.get_real_data_new.dtuPower - aktuelle Einspeißung (4321 = 432,1W)
(=hoymiles-wifi.0.get_real_data_new.sgsData.0.activePower)
(hoymiles-wifi.0.get_real_data_new.pvData.0.power = Watt bei Panel0, jetzt)
(hoymiles-wifi.0.get_real_data_new.pvData.1.power = Watt bei Panel1, jetzt)
hoymiles-wifi.0.get_real_data_new.dtuDailyEnergy (1234 = 1,23 kWh heute)
Mit dem Adapter kommen ja recht schnell Daten, so dass man darauf reagieren könnte. @saibot852 Ja, dein Szenario macht Sinn für mich, ich schaue mir
das in zwei Wochen an; vorher komme ich wohl leider nicht dazu.
hoymiles-wifi.0.get_real_data_new.sgsData.0.powerLimit (999=100% - dies wäre interessant schreibend für die Nulleinspeißung; nächstes Projekt wenn ich wieder Zeit habe) Per App ergibt 95% einen Wert von 950, per Befehlszeile:
$ hoymiles-wifi --host 192.168.1.2 set-power-limit
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! Danger zone! This will change the power limit of the dtu. !!!
!!! Please be careful and make sure you know what you are doing. !!!
!!! Only proceed if you know what you are doing. !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Do you want to continue? (y/n): y
Enter the new power limit (0-100): 90
Setting power limit to 90%
Are you sure? (y/n): y
Set-power-limit Response:
dtu_sn: "414393xxxxxx"
time: 1724xxxxxx
action: 8
tid: 1724xxxxxx
Damit geht der Wert powerLimit auf 900. Die Sicherheitsabfragen sind eine zusätzliche Herausforderung...
@mcm1957
Ein sehr guter genereller Warnhinweis!
Um so wichtiger, als kurz nach meiner letzen Version mein Raspberry Probleme machte, deren Eingrenzung im Try- and Errorverfahren Tage brauchte und am Ende war es aber nur das Netzteil und ein anderes Dockupdate.
Leider habe ich noch keine freiwilligen Tester und Feedbacks.
@mcm1957 Danke für den Warnhinweis.
Wo und wie lasse ich nun am Besten testen? Das hatte ich noch nicht richtig verstanden.
Ja, das mit der Integration der Bibliothek wäre nett, aber da brauche ich wohl noch etwas Zeit.
