USV für Pi3 mit neuem Funkmodul und ELV Gehäuse

Allgemeines zur HomeMatic Haussteuerung

Moderator: Co-Administratoren

HMSchrottix
Beiträge: 32
Registriert: 27.12.2018, 21:09
Danksagung erhalten: 1 Mal

Re: USV für Pi3 mit neuem Funkmodul und ELV Gehäuse

Beitrag von HMSchrottix » 24.01.2019, 15:47

Hallo deimos,

danke für die schnelle Antwort.
Das klingt interessant. Die Vorteile von Line Interactive hätte ich auch gern. Aber als Ersatz-Kochplatte wollte ich die USV dann auch nicht verwenden. Die Hitzeentwicklung hat mich ein wenig in Panik versetzt.
Ich dachte mir: Montagsgerät oder China-Schrott? Im Zweifel habe ich dann die Rücksendung mit ausführlicher Begründung gewählt. Der Verkäufer konnte oder wollte mir nichts zu meinen Argumenten mitteilen.
Deshalb will ich vor einem Neukauf erst mal hier im Forum lesen und nach Erfahrungen fragen.
Muss das wirklich so heiß werden?
Ich hoffe, es gibt auch bessere Alternativen.

Gruß von HMSchrottix

Benutzeravatar
deimos
Beiträge: 5398
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 957 Mal
Kontaktdaten:

Re: USV für Pi3 mit neuem Funkmodul und ELV Gehäuse

Beitrag von deimos » 24.01.2019, 15:57

Hi,

37 Grad ist jetzt nicht grade "sehr" heiß, das ist einfach gut warm. Mein Fernseher erzeugt da z.B. nach einer Stunde Betrieb deutlich mehr.

Viele Grüße
Alex

HMSchrottix
Beiträge: 32
Registriert: 27.12.2018, 21:09
Danksagung erhalten: 1 Mal

Re: USV für Pi3: Erfahrungen+Learnings mit FSP Fortron EP 650

Beitrag von HMSchrottix » 01.02.2019, 21:56

Hallo zusammen,
Ich möchte an dieser Stelle meine persönlichen (eher schlechten) Erfahrungen und Learnings bei der Einrichtung einer USV für meinen Raspi 3B+ teilen. Vielleicht hilft es ja einem Interessierten bei der Entscheidung oder Umsetzung.
Nach gründlicher (na ja, dachte ich...) Recherche im Forum hatte ich mich für eine FSP Fortron EP 650 SP für knapp über 50,-EU entschieden:
- recht klein von den Abmaßen, 2x Schuko
- eine Anleitung bei ELV für die Integration mit dem Raspi
- eine schöne Anleitung von JSP im Forum für die weitere Integration in die HM-Welt
- laut ELV-Shop eine "Leistungsaufnahme" von 10,8W (dazu später mehr!)
- hinreichend Leistung für Minimalverbraucher Raspi, Router, Switch und HM-Komponenten
Also sollte alles schnell und reibungslos über die Bühne gehen. Aber leider kam es ganz anders!
Erst ging alles sehr schnell. Bestellt, ausgepackt und angeschlossen. Bestens.

Das vor die USV geschaltete Messgerät zeigt mir gleich mal knapp 40 Watt Verbrauch an. Ohne Last, weil ja erst mal Aufladen des Akku dran ist. Also gut, wenn der Akku voll ist, wird der Verbrauch wohl auf die von ELV angegebene "Leistungsaufnahme" sinken. Oh, ich Träumer!

Nach ausreichend Stunden hörte die LED auf zu blinken, also laut magerer Anleitung voll aufgeladen. Das Messgerät zeigt aber immer noch einen Verbrauch von ca. 38Watt (leicht schwankend). Fast 4 mal so viel wie bei ELV angegeben!!! Und damit mehr als alle Minimalverbraucher zusammen, die ich anschließen will. Und es war noch KEIN Gerät angeschlossen!

Meine alte APC BE550G GR verbraucht laut gleichem Messgerät nur 4-6 Watt. Das ist zwar ein "Offline-Gerät", fängt aber auch nach mehr als 6 Jahren mit dem ersten Akku jeden Stromausfall sauber ab. Hat nie Probleme gemacht, aber 8 Steckdosen, von denen nur 4 gepuffert nutzbar sind? Was soll das? Im Büro ist das für unwichtige Geräte als Steckerleiste OK, aber als Ausfallschutz für Homematic, Router usw. sinnlos.

Dieser Eigenverbrauch der EP650 ist in meinen Augen schon der Todesstoß für das Projekt. Ich habe mal den Hersteller kontaktiert und um Aufklärung gebeten. Mal sehen, was da raus kommt.

Aber erst mal weiter. Beim Anschluss des Raspi allein hat sich an der Anzeige praktisch nichts geändert. Klar, der braucht ja so wenig, dass das Messgerät nur beim Neustart des Raspi kurzzeitig mal 5 Watt als zusätzlichen Peak anzeigt.
Der Umschalttest mit Hilfe eines Zwischenschalters (keinen Stecker ziehen, wie hier im Forum gewarnt wird) funktioniert einwandfrei. Also ran an den Raspi, USB-Kabel anstecken und die Anleitungen abarbeiten.
ELV-Anleitung:
Ich habe als Werkzeuge Firefox für den HM-GUI, Filezilla, Kate und Putty unter Linux verwendet. Alle Konfig-Files waren schnell zu finden, mit Filezilla auf den PC holen, ändern und wieder zurück. Neustart (Warmstart über den GUI) und ...NICHTS. Auch kein Ergebnis bei der manuellen Abfrage mit „upsc ep650@localhost“ via Putty. Dann kam eine stundenlange Orgie wiederholten Prüfungen, Fehlersuche, Forum-Recherche und direkten Nachfragen bei JSP. Alles war richtig, aber geht nicht.
Erst dann habe ich angefangen, den Fehler nicht bei mir zu suchen, sondern die Konfig-Vorgaben von ELV in Frage zu stellen. Da gibt es den Eintrag: Mode=netserver. Im Forum gibt es auch Beispiele mit einem NAS als „netclient“, also warum nicht probieren?
Plötzlich hatte ich einen ersten Eintrag (warum vorher nichts kam, ist mir ein Rätsel) als CCU-Alarmmeldung „NOCOMM“ und im Logfile folgende Einträge:
Jan 30 22:26:45 localhost daemon.info blazer_usb[437]: Startup successful
Jan 30 22:26:45 localhost daemon.warn upsd[438]: /etc/upsd.conf is world readable
Jan 30 22:26:45 localhost daemon.err upsd[438]: not listening on 192.168.178.33 port 3493
Jan 30 22:26:45 localhost daemon.err upsd[438]: getaddrinfo: Temporary failure in name resolution

Oh, da stimmt wohl etwas nicht mit dem Port! Laut ELV-Anleitung soll der Port in der „ups.conf“ auf „auto“ stehen. Warum nicht gleich den richtigen Port angeben wie im Konfig-File „upsd.conf“ gefordert? Also eigenmächtig von „auto“ nach „3493“ geändert, zusätzlich den Mode wieder nach „netserver“ und Neustart.
Und tatsächlich: plötzlich geht alles! Via Putty kann ich die Daten manuell abfragen, die Alarmmeldungen werden im GUI angezeigt und im Log stehen die Einträge:
Jan 30 23:03:41 homematic-raspi daemon.info upsd[576]: listening on localhost port 3493
Jan 30 23:03:41 homematic-raspi daemon.info upsd[576]: Connected to UPS [ep650]:
Wieso bei mir das „auto“ nicht funktioniert und ich erst mal auf „netclient“ ändern musste, um überhaupt eine Reaktion im Raspi zu bekommen, bleibt für mich ein Rätsel.

Nun zur Auswertung der USV-Daten mit einem HM-Programm in Anlehnung an die Anleitung von JSP. Dank der guten Beschreibung von JSP waren die für mich notwendigen Schritte schnell und leicht gemacht. Aber wie man schon ahnt, die Variablen blieben einfach leer!

1. Problem:
Der folgende Aufruf geht bei mir nicht (warum auch immer):
system.Exec("upsc ep650@localhost ups.status", &stdout, &stderr);

Auf meinem Raspi muss die Pfadangabe zum Programm mit drin sein:
system.Exec("/usr/bin/upsc ep650@localhost ups.status", &stdout, &stderr);

2. Problem:
Mit dem folgenden Aufruf bekomme ich die Daten nicht in die Systemvariable z.B UPS.VoltBatterie. Die Variable „vb“ wird zwar befüllt, aber die Systemvariable „UPS.VoltBatterie“ bleibt leer.
var vb = dom.GetObject("UPS.VoltBatterie");
string stdout;
string stderr;
system.Exec("/usr/bin/upsc ep650@localhost battery.voltage", &stdout, &stderr);
vb.State(stdout);

So geht es bei mir einfach und fehlerfrei:
system.Exec("/usr/bin/upsc ep650@localhost battery.voltage", &stdout, &stderr);
dom.GetObject("UPS.Akku.Spannung").State(stdout);

3. Problem:
Der Aufruf für ups.status nur die Strings „OL“ oder „OB“. Die wollte ich gleich in besser lesbarer Form in die Systemvariable packen. Aber Pustekuchen! Ein Vergleich ging nicht!
if (stdout == "OL") {
upsstatus = "Netzbetrieb";
}else {
upsstatus = "Akkubetrieb";
}
Mit WriteLine war kein Fehler zu entdecken. Was jetzt? Also mal mit Find, Contains und Trim experimentiert. Ja und das war‘s! Mit dem Systemaufruf kommt noch irgendein unsichtbarer Müll/Sonderzeichen in den String. Also erst mal:
stdout = stdout.Trim();
Dann der Vergleich und alles ist gut. Also Vorsicht bei der Weiterverwendung der abgefragten USV-Daten, die als String geliefert werden.

4. Problem:
Nachdem die Daten nun schön erfasst werden (Test mit virtueller Taste), wollte ich nun auf die Systemvariable „Alarmzone 1“ triggern, so wie in der Anleitung von JSP schön beschrieben. Aber wieder mal Fehlanzeige.
Auf meinem Raspi triggert diese Variable nichts. Das Zeit-Polling läuft wie zu erwarten einwandfrei und aktualisiert die Systemvariablen. Wenn ich aber die Zeitsteuerung wegnehme, passiert gar nichts mehr. Die Alarmmeldungen werden schön bei jeder Umschaltung im GUI angezeigt, aber das Programm bleibt tot. Egal ob ich auf „ausgelöst“ oder „nicht ausgelöst“ oder „Änderung“ oder „Aktualisierung“ triggere. Da passiert nichts.

Als Workaround lasse ich also das Zeit-Polling laufen und triggere die Folgeaktionen über die Änderung der Systemvariablen „ups.status“. Die Änderung kommt zwar durch das Polling verspätet, aber so lange sollte die USV ja auf jeden Fall Akku-Strom für den Raspi liefern.
Nun muss ich nur noch den geordneten Shutdown implementieren.
Ich bin also noch nicht am Ziel.
Zuletzt geändert von HMSchrottix am 05.02.2019, 23:55, insgesamt 1-mal geändert.

HMSchrottix
Beiträge: 32
Registriert: 27.12.2018, 21:09
Danksagung erhalten: 1 Mal

Teil 2 USV für Pi3: Erfahrungen+Learnings mit FSP Fortron EP 650

Beitrag von HMSchrottix » 02.02.2019, 21:44

Hallo,
Hier geht es weiter mit meinen Erfahrungen+Learnings mit FSP Fortron EP 650.

Vorab noch ein Nachtrag zum Problem 4 von oben:
Ich konnte einen Workaround finden: Da die Abfrage auf Änderung der Systemvariablen "Alarmzone 1" nicht funktioniert, habe ich die Aktualisierung in allen Richtungen abgefragt. BINGO! Jetzt triggert das Programm auch ohne Zeit-Polling zuverlässig. Damit lese ich Daten der EP650 ohne Zeitverzug aus und starte dann Folgeaktionen mit einem Trigger über die Variable "ups.status".

Nun zum Shutdown:
Nach langer Suche im Forum bin ich auf einen Beitrag von "sammy" + "alchy" gestoßen:
viewtopic.php?f=19&t=46313&start=10

Code: Alles auswählen

system.Save();
WriteLine("regadom gesichert");
string stdout;string stderr;
string cmd = "/sbin/poweroff"; 
system.Exec(cmd, &stdout, &stderr);
WriteLine("Befehl "#cmd #" abgeschickt");
Das funktionierte auf zwar Anhieb, ABER VORSICHT: SYSTEM TOD
Ich habe extra einen virtuellen Taster als Trigger gewählt (lange drücken) und prüfe zusätzlich mit UND die originale Systemvariable "Anwesenheit", ob die CCU im Normalmodus arbeitet. Das waren die Hinweise im Forum, wie man ein Ausführen der Programme nach einem Systemstart vermeiden kann.
Und jetzt das!
Wieso die Anweisung ausgeführt, obwohl niemand den virtuellen Taster auslösen kann, ist mir ein Rätsel?
Ich bin ja mal gespannt, ob mir jemand helfen kann.

Und ich hab' keine Ahnung, wie ich den Raspi nach einem Stromausfall runter fahren soll...

Gruß von HMSchrottix

Antworten

Zurück zu „HomeMatic allgemein“