USV für Raspberry Pi

Begonnen von DerPeter, 14 Juni 2015, 11:38:49

Vorheriges Thema - Nächstes Thema

alpha1974

Die üblichen Fehlerquellen (Firmware? Netzteil?) gecheckt? Wenn es nur "ab und zu" unsinnige Werte gibt, hat vielleicht das Netzteil Probleme mit Spannungsschwankungen und die USV ist verwirrt....

BTW: Es gibt seit gestern für die UPS Pico eine neue Firmware (0x5C), die man im pimodules-Forum herunterladen kann.
FHEM/Z-Wave USB-Dongle + div. Devices

Bytechanger

Hallo,

ich hatte gestern auch das Erlebnis, dass die Pico Firmware gesponnen hat. Sie meldete bei einem Reading plötzlich, dass Batteriebetrieb vorläge und die Firmware würde hängen (Pico_run gleich).
Daher habe ich mein Notify angepasst, dass es mehrere Readings geben muss, bis Alarm ausgelöst wird.

USV:.* {

         if (Value("USV_Batteriebetrieb")!~ /^\d+$/) {
              fhem "set USV_Batteriebetrieb 0";
         }
         my $bat=int(Value("USV_Batteriebetrieb"));

        if("$EVENT" =~ m/PowerSource:\sBAT/) {
            $bat=$bat+1;
            fhem "set USV_Batteriebetrieb $bat";
            if ($bat==3) { SendSMS(0,'FHEM Verdacht des Stromausfalls!', 'Verdacht:');  }
        }

       if("$EVENT" =~ m/PowerSource:\sRPI/) {
           fhem "set USV_Batteriebetrieb 0";
           if ($bat>=3) { SendSMS(1,'FHEM Strom ist wieder da!', 'Hinweis:');  }
       }

       if("$EVENT" =~ m/VoltageBAT:/) {
           #Zustand Batterie, bei 3.15 V wird der Raspi automatisch heruntergefahren !! ---
           if (ReadingsVal("USV", "VoltageBAT", "99") < 3.3 && ReadingsVal("USV", "PowerSource", "99") eq "BAT")
              {
                if ( Value("USV_BatterieCritical") eq "off") { SendSMS(1,'FHEM: Notstromversorgung wird kritisch schwach!', 'WARNUNG:');  }
                if ( Value("USV_BatterieCritical") ne "on") { fhem "set USV_BatterieCritical on"; }
              }
           else {
                  if ( Value("USV_BatterieCritical") ne "off") { fhem "set USV_BatterieCritical off"; }
                }
      }

if("$EVENT" =~ m/Pico_run:/) {   
       if (Value("USV_FirmwareRunning")!~ /^\d+$/) {
            fhem "set USV_FirmwareRunning 0";
        }

        my $run=int(Value("USV_FirmwareRunning"));

        if (ReadingsVal("USV", "Pico_run", "99") eq "running") {
          fhem "set USV_FirmwareRunning 0";
        }

       if (ReadingsVal("USV", "Pico_run", "99") ne "running") {
          $run=$run+1;
          fhem "set USV_FirmwareRunning $run";
          if ($run==3) { SendSMS(1,'FHEM: Notstromversorgung Fehler in der Firmware!', 'WARNUNG:');  }
        }
 
  }

}


Greets

Byte

alpha1974

Guter Ansatz, setzt aber voraus, dass das USV-Device bei jedem poll ein Event erzeugt? Mir war das zu viel "Geplauder", weshalb ich dem USV-Device ein event-on-change-reading-Attribut verpasst habe, so dass es nur dann ein (einmaliges) Event erzeugt, wenn sich ein Reading auch ändert.

Das (bei mir nur einmalige) Event bei einer Änderung von PowerSource auf BAT will ich mit DOIF mit den Attributen wait und do resetwait entsprechend zeitverzögert auswerten (also Alarm erst, wenn sich innerhalb der wait-Zeitspanne PowerSource nicht wieder ändert). Bin aber gerade noch im Lernstadium, was die Leistungsfähigkeit von DOIF angeht. Meine ersten Versuche in anderem Kontext (Heizungssteuerung) sind aber vielversprechend.
FHEM/Z-Wave USB-Dongle + div. Devices

Bytechanger

Hallo, hört sich gut an, wie hast Du es gelöst?

Wäre das ein Ansatz, oder habe ich da einen Denkfehler drin, mit DOIF habe ich noch nicht so viel gearbeitet!

define do_USV_BattBetrieb DOIF ([USV:PowerSource] eq "BAT") (\
{\
  SendSMS(0,'FHEM Verdacht des Stromausfalls!', 'Verdacht:');;\
  fhem "set USV_Batteriebetrieb on";;\
})\
DOELSEIF ([USV:PowerSource] eq "RPI")(\
{\
  if ( Value("USV_Batteriebetrieb") eq "on") { SendSMS(1,'FHEM Strom ist wieder da!', 'Hinweis:');; }\
  fhem "set USV_Batteriebetrieb off";;\
})
attr do_USV_BattBetrieb wait 30:30

define do_USV_Firmware DOIF ([USV:Pico_run] ne "running") (\
{\
  SendSMS(1,'FHEM: Notstromversorgung Fehler in der Firmware!', 'WARNUNG:');;\
  fhem "set USV_FirmwareRunning off";;\
})\
DOELSEIF ([USV:Pico_run] eq "running")(\
{\
  fhem "sset USV_FirmwareRunning on";;\
})
attr do_USV_Firmware wait 30:30

define do_USV_BatVolt DOIF ([USV:VoltageBAT] < 3.3 AND [USV:PowerSource] eq "BAT") (\
{\
  SendSMS(1,'FHEM: Notstromversorgung wird kritisch schwach!', 'WARNUNG:');;\
  fhem "set USV_BatterieCritical on";;\
})\
DOELSE (\
{\
  fhem "set USV_BatterieCritical off";;\
})
attr do_USV_BatVolt wait 10:10


Greets

Byte

alpha1974

Wozu ist denn das Device USB_Batteriebetrieb und dessen Abfrage innerhalb von DOIF? Ergibt sich nicht schon aus USV:PowerSource = "BAT", dass das Device auf Batteriebetrieb ist? Nur als Bedingung für die Meldung "Strom wieder da" (nur, wenn PowerSource=RPI und USB_Batteriebetrieb=on) scheint mir das entbehrlich zu sein, weil das DOIF ja ohnehin nur bei PowerSource=RPI oder BAT triggert.

Um zu verhindern, dass "Strom wieder da" zu früh gesendet wird, also z.B. wenn der Strom zwar kurz wieder da ist, aber dann wieder weg ist (innerhalb der 30 Sekunden-Zeitspanne des wait-Attributs), kann man auch das repeatsame-Attribut verwenden. Dann wird beim Event "BAT" einmalig die Nachricht "Strom weg!" geschickt, wenn sich innerhalb von 30 Sekunden nichts ändert. Die nächste Nachricht kommt dann erst wieder (nämlich "Strom wieder da!"), wenn das Event "RPI" länger als 30 Sekunden bestehen bleibt.


Bei mir sieht das so aus (mit event-on-change-reading .*-Attribut im USV-Device):
DEF       
([USV:PowerSource] eq "BAT") (set jabber msg xxxx@xxxx.xxx FHEM: Pico USV seit 30 Sek. auf BAT)
DOELSEIF
([USV:PowerSource] eq "RPI") (set jabber msg xxxx@xxxx.xxx FHEM: Pico USV seit 30 Sek. auf RPI)

Attributes:
   do         resetwait
   repeatsame 1:1 
   wait       30:30


FHEM/Z-Wave USB-Dongle + div. Devices

Bytechanger

Hallo,

danke für die Infos. Die Dummys sind noch aus der alten Zeit, damit eine Nachricht nur einmal, bei Zustandswechsel raus geht.
Ist bei DOIF nicht mehr erforderlich.

Ich programmiere zwar in anderen Sprachen, finde die Doku aber etwas un-/missverständlich, was die DOIF Attribute angeht.
Könntest Du mir die hier erklären:
wait ist klar: bei notify wird die Wartezeit gewartet, dann geprüft, ob Bedingung erfüllt ist...

do resetwait ??
repeatsame ??


Auf welchen Pollintervall hast Du die USV Abfrage?
Ist meine Kontrolle der Batteriespannung OK, oder kann man sie verbessern (Hintergrund ist, dass ich eine Nachricht bekomme, bevor Gerät endgültig aus geht)...

Greets

Byte

alpha1974

Zitat von: Bytechanger am 29 Februar 2016, 18:05:52
danke für die Infos. Die Dummys sind noch aus der alten Zeit, damit eine Nachricht nur einmal, bei Zustandswechsel raus geht.
Ist bei DOIF nicht mehr erforderlich.
Ah, dachte ich mir doch.
Zitat
Ich programmiere zwar in anderen Sprachen, finde die Doku aber etwas un-/missverständlich, was die DOIF Attribute angeht.
Könntest Du mir die hier erklären:
wait ist klar: bei notify wird die Wartezeit gewartet, dann geprüft, ob Bedingung erfüllt ist...

do resetwait ??
repeatsame ??
Nun ja, ich programmiere eigentlich überhaupt nicht, sondern wusele mich so durch, das meiste eher nach trial and error... Macht aber nichts, da ich mir des Risikos, dass etwas nicht so läuft, wie es soll, bewusst bin und ich mich da sehendes Auges, aber erhobenen Hauptes hineinstürze (würde mich zwar ärgern, wenn ich mal z.B. versehentlich die Heizung via ebus schrotte, weil ich einen Parameter unwissentlich falsch einstelle und das Teil abraucht, aber... no risk no fun :-)).


Meine Interpretation der o.g. DOIF-Attribute: do resetwait setzt den Timer zurück, wenn dasselbe Event nochmals kommt.
Interessanter ist repeatsame. Im o.g. Beispiel "1:1" führt es dazu, dass jedes der beiden Kommandos (Nachricht "BAT" / Nachricht "RPI") immer nur ein einziges Mal ausgeführt wird, egal wie oft das dazugehörige Event eintritt, und dann erst wieder, wenn zwischenzeitlich das andere Kommando einmal ausgeführt worden ist. Ich habe das mühselig herausgefunden, als ich die eigentlich sehr simple Aufgabenstellung lösen wollte "Wohnzimmertür 30 Sek. lang auf = eingestelltes Heizprogramm speichern und Heizung aus" + "Wohnzimmertür 30 Sek. lang zu = Heizung mit vorherigem Heizprogramm wieder an".

Auslösendes Event ist ein Magnetschalter, der auf 0 oder 1 geht, wenn die Tür geöffnet bzw. geschlossen wird. Das Problem bestand trotz (oder eher wegen) "wait 30" darin, dass das Event "Tür auf" auch dann triggert, wenn die offene Tür nach dreißig Sekunden mal kurz geschlossen wird und dann wieder geöffnet wird und offen stehen bleibt. Im Grunde ist das ja egal, wenn dann der Befehl "Heizung aus" nochmals ausgeführt wird, allerdings merkt sich das DOIF beim ersten Tür-Auf-Event das zuvor eingestellte Heizungsprogramm... Würde das dann zweimal hintereinander ausgeführt, bleibt es auf "Standby" stehen.

Ich habe lange mit Dummy-Variablen rumprobiert, bis ich auf das ziemlich geniale repeatsame gestoßen bin. Dadurch wird derselbe Befehl immer nur (höchstens) x-Mal hintereinander ausgeführt = bei repeatsame 1:1 geht es zwangsweise immer nur abwechselnd. Hat sich in der Praxis als sehr hilfreich erwiesen, weil das Heizprogramm, das vor dem Lüften eingestellt war, auch dann wieder zuverlässig gesetzt wird, wenn der Wind (oder - wahrscheinlicher - die Kinder) die Tür beim Lüften mal kurz zuschlagen und dann innerhalb von 30 Sekunden wieder öffnen... Nun ja, viel Aufwand für wenig Nutzen, aber der Fun-Faktor und meine Begeisterung über repeatsame waren es mir wert :-)

Zitat
Auf welchen Pollintervall hast Du die USV Abfrage?
15 Sekunden. Aber ich habe auch nur einen 450er-Akku. Das Poll-Intervall sollte daher tunlichst kürzer sein als dessen Laufzeit :-)
Insgesamt gefällt mir das ganze Gepolle aber auch nicht so richtig. Über event-on-change-reading kann man zwar etwas Ruhe in die Log-Files bringen, aber lieber wäre mir eine Interrupt-Lösung. "Ioannis", der nach meinem Eindruck der einzige Entwickler bei pimodules ist, hat mir geschrieben, er fände das auch besser und wolle es künftig mal umsetzen. Wann das sein wird, weiß aber keiner.

Zitat
Ist meine Kontrolle der Batteriespannung OK, oder kann man sie verbessern (Hintergrund ist, dass ich eine Nachricht bekomme, bevor Gerät endgültig aus geht)...
Habe ich nicht getestet (und kann ich "auf dem Papier" mangels ausreichender Programmierkenntnisse leider auch nicht ohne Test beurteilen). Für mich besteht da wegen des kleinen Akkus auch kein richtiger Nutzwert. Sobald die Stromversorgung länger als 30 Sek. weg ist, soll der Raspi das Nötige schnellstmöglich veranlassen: Nachricht schicken, vielleicht vorher noch prüfen, ob andere Geräte noch Strom haben... z.B. Abfrage bei den Z-Wave Wall Plugs und das Ergebnis mitteilen... dann kann und soll er erstmal runterfahren. Die UPS Pico fährt ihn ja wieder hoch, wenn wieder Strom da ist. Eine großartige Wartezeit muss der kleine Akku dann nicht überbrücken.

Naja, wie schon an anderer Stelle gesagt: Nette Spielereien, eine Herz-Lungen-Maschine würde ich da aber nicht dranhängen.
FHEM/Z-Wave USB-Dongle + div. Devices

Bytechanger

Danke für die ausführliche Antwort.

Mit der Tür/Fenster hört sich interessant an und könnte ich, wenn ich es richtig verstanden habe, auch für meinen "EinbruchAlarm" verwenden.
Szenario ist folgendes: Habe eine Terrassentür mit Griffkontakt und Öffnungskontakt.

Der Griffkontakt meldet etwa 3 Sekunden zeitverzögert seinen Zustand.
Wenn nun der Öffnungskontakt "offen" meldet, sollte der Türkontakt auf "offen" sein, sonst wurde die Tür aufgehebelt!

Das würde ich gerne mit DOIF lösen. Also Öffnungskontakt>"offen"->10 Sekunden warten->Griffkontakt prüfen...
Sollte in der Zwischenzeit die Tür nochmals geschlossen und wieder geöffnet werden, 10 Sekunden erneut warten...
(Kinder)



Greets

Byte