Probleme mit Pushover unter Openhab3.2

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
Selter
Beiträge: 59
Registriert: 9. Mär 2018 16:06

Probleme mit Pushover unter Openhab3.2

Beitrag von Selter »

Hallo,

ich bin OH2.5 nach OH3.2 umgezogen - alle Rules (Textfiles) funktionieren soweit auch.
Aber Pushover macht Probleme: manchmal werden Nachrichten nicht versendet - z.B. wurde diese Rule getriggert und alles ausgeführt, aber ich habe keine PO bekommen.

Code: Alles auswählen

rule "Astro Test"
when
	Channel "astro:sun:test:noon#event" triggered START
then
  	 EG_az_r_Rollershutter.sendCommand(50)

  	logInfo("DAYLIGHT", "TEST - Astro Noon")
	postUpdate(EventLog, "TEST - Astro Noon")        // eventlog.rules

    Thread::sleep(100)

	val actions = getActions("pushover", "pushover:pushover-account:soundNone")
    actions.sendHtmlMessage("TEST - Astro Noon", "openHAB3") 

end
Zum Testen habe ich einen Switch erstellt, der eine PO versendet - das funktioniert dann.

Code: Alles auswählen

rule "Pushover Test"
    when
        Item pushover received command
    then
        switch(receivedCommand) {
            case ON: {
                
                // sendPushoverMessage(pushoverBuilder("test message").withPriority(1).withSound("magic"))
                val actions = getActions("pushover", "pushover:pushover-account:soundNone")
                actions.sendHtmlMessage("Pushover <font color='green'>ON</font>! soundNone", "openHAB3")
                 logInfo("PUSHOVER", "--> on ")

            }

            case OFF: {
                val actions = getActions("pushover", "pushover:pushover-account:soundPushover")
                actions.sendHtmlMessage("Pushover <font color='green'>OFF</font>! soundPushover", "openHAB3")
                 logInfo("PUSHOVER", "--> off ")

            }
        }
end
Ich hoffe, Ihr könnt mir helfen ...
openHAB 3.2 in einer Debian-VM mit openHABian unter Proxmox 6.4-13 auf Intel NUC 5i3ryh

int5749
Beiträge: 1161
Registriert: 4. Nov 2019 22:08
Answers: 9

Re: Probleme mit Pushover unter Openhab3.2

Beitrag von int5749 »

Kann es evtl sein, dass die erste Rule nach den (für mich) seltsamen Aufruf des postUpdate abbricht und somit gar nicht erst zum versenden der Nachricht kommt? Evtl baust Du einmal ein LogInfo direkt vor den ThreatSleep ein.

Des Weiteren ist ThreatSleep unschön und sollte ggfs mit einem Timer gelöst werden, da ThreatSleep die Rule für die angegebene Zeit anhält.

Das valAction empfiehlt sich direkt zu Anfang, wenn alle Eintrittswahrscheinlichkeiten erfüllt sind, In der 2, Rule würdest Du dies so 1x einsparen. Wenn Du es so in allen Rules handhabst, könnte da Optimierungspotential stecken;-)

VG
openHAB 4.1.0 Release mit openHABian in einem Debian Bookworm (LXC) unter Proxmox 8.1.3

Selter
Beiträge: 59
Registriert: 9. Mär 2018 16:06

Re: Probleme mit Pushover unter Openhab3.2

Beitrag von Selter »

Danke für die Antwort und den Hinweis bzgl. Thread::sleep - das kann wahrscheinlich auch ganz raus.

Ich habe mal mit dieser Version getestet - Eventlog aktualisiert erscheint im Log, die Rule bricht also nicht ab.
Diesmal kam auch die PO-Nachricht an.

Code: Alles auswählen


rule "Test PO1"
when
    Time cron "0 15 14 ? * SUN,MON,TUE,WED,THU,FRI,SAT *"        // jeden Tag
    // Time cron "0 31 9 ? * MON,TUE,WED,THU,FRI *"
then
    
  	EG_az_r_Rollershutter.sendCommand(10)

  	logInfo("TEST", "TEST - Astro Noon")
	postUpdate(EventLog, "TEST - Astro Noon")        // eventlog.rules

    logInfo("TEST", "TEST - Astro Noon / Eventlog aktualisiert")

    Thread::sleep(100)
    val actions = getActions("pushover", "pushover:pushover-account:soundNone")
    actions.sendHtmlMessage("TEST - Astro Noon", "openHAB3") 
 
end
Meinst Du "val" sollte dann gleich direkt nach "then" eingefügt werden?
openHAB 3.2 in einer Debian-VM mit openHABian unter Proxmox 6.4-13 auf Intel NUC 5i3ryh

Benutzeravatar
udo1toni
Beiträge: 13857
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Probleme mit Pushover unter Openhab3.2

Beitrag von udo1toni »

Stopp. :)

Also, der Code ist erst mal etwas unkonventionell, sollte aber so durchlaufen. Die Formatierung ist hier im Forum unglücklich, weil die Forensoftware einen Tab alle acht Zeichen setzt, während der normale Tab-Abstand in den diversen Editoren gewöhnlich vier beträgt.

Hast Du tatsächlich ein Item namens EventLog? Wozu?

Thread::sleep(100) hält die Rule für 100 Millisekunden an. Das ist - in diesem Zeitrahmen - in Ordnung.
Allerdings bringt es rein gar nichts, außer natürlich eine längere Ausführungszeit der Rule. Pushover hat Laufzeiten von mehreren Sekunden, so dass die 100 Millisekunden ganz weit in die Schwankungen rein fallen. Innerhalb der Rule gibt es keinen Grund zu warten, das ist höchstens sinnvoll, wenn man ein Item beschreibt (mit postUpdate) und direkt im Anschluss dieses Item wieder verwendet. Da openHAB asynchron arbeitet, ist mit hoher Wahrscheinlichkeit das postUpdate noch nicht fertig ausgeführt, wenn das Item wieder gelesen wird. Beispielcode:

Code: Alles auswählen

logInfo("test","Status 1 von MyItem: {}",MyItem.state)
MyItem.postUpdate(if(MyItem.state != ON) ON else OFF)
logInfo("test","Status 2 von MyItem: {}",MyItem.state)
Thread::sleep(100)
logInfo("test","Status 3 von MyItem: {}",MyItem.state)
MyItem ist ein Switch Item. Der Status des Items wird durch den Code gewechselt. Ist der Status ungleich ON, so wird der Status auf ON gesetzt, ansonsten auf OFF.
Im Log wird unmittelbar vor und nach dem postUpdate der Status ausgegeben, dann noch mal nach 100 Millisekunden.

Es gibt nun kein garantiertes Verhalten, aber mit einiger Wahrscheinlichkeit werden die erste und die zweite log-Zeile den gleichen Status anzeigen, während die dritte log-Zeile einen anderen Status anzeigt. Das liegt daran, dass die DSL das postUpdate delegiert und unmittelbar die nächste Codezeile ausführt.

Wie gesagt hast Du im Beispielcode rein gar nichts von dieser Verzögerung.

Warum das pushover nicht zuverlässig funktioniert, kann ich allerdings auch nicht sagen.

Bei der zweiten Testrule kannst Du die lokale Konstante actions leider nicht an einer Stelle definieren, denn der Inhalt ist unterschiedlich (einmal mit, einmal ohne Ton)
Dennoch ist der Code so eher suboptimal. Du kannst als Namen für das Objekt übrigens beliebige Begriffe nehmen also z.B.

Code: Alles auswählen

rule "Pushover Test"
when
    Item pushover received command
then
	val pushNone  = getActions("pushover", "pushover:pushover-account:soundNone")
	val pushSound = getActions("pushover", "pushover:pushover-account:soundPushover")
	logInfo("PUSHOVER", "--> {}",if(receivedCommand == ON) "on" else "off")
	switch(receivedCommand) {
		case ON : pushSound.sendHtmlMessage("Pushover <font color='green'>ON</font>! soundNone", "openHAB3")
		case OFF:  pushNone.sendHtmlMessage("Pushover <font color='green'>OFF</font>! soundPushover", "openHAB3")
	}
end
Die beiden Objekte pushNone und pushSound sind Handles, um aus der Rule heraus auf die Action im Binding zugreifen zu können. Der Name ist gleichgültig.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Selter
Beiträge: 59
Registriert: 9. Mär 2018 16:06

Re: Probleme mit Pushover unter Openhab3.2

Beitrag von Selter »

Vielen Dank für die ausführliche Erklärung!

Eventlog dient dazu bestimmte Infos/Logs in der Sitemap anzuzeigen - das habe ich hier gefunden: https://community.openhab.org/t/display ... p/11918/5
openHAB 3.2 in einer Debian-VM mit openHABian unter Proxmox 6.4-13 auf Intel NUC 5i3ryh

Benutzeravatar
udo1toni
Beiträge: 13857
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Probleme mit Pushover unter Openhab3.2

Beitrag von udo1toni »

Selter hat geschrieben: 5. Jul 2022 17:31 Eventlog dient dazu bestimmte Infos/Logs in der Sitemap anzuzeigen - das habe ich hier gefunden: https://community.openhab.org/t/display ... p/11918/5
reichlich kompliziert :) man kann - zumindest wenn man openHAB mittels openHABian aufsetzt - sehr bequem über die Webschnittstelle von frontail in das laufende Log von openHAB reinschauen. Ein einzelnes Item erlaubt ja lediglich, die letzte Meldung zu sehen, welche durch das postUpdate in den Status geschrieben wurde. Eine Gruppe mit x Items erlaubt lediglich, die letzten x Meldungen zu sehen, und man muss erheblichen Aufwand betreiben, um eine vernünftige Anzahl Meldungen zu Gesicht zu bekommen. Da die Liste in der Oberfläche nicht frei angeordnet werden kann, muss bei jedem Update die gesamte Liste umkopiert werden, so dass man die Menge an Einträgen auch nicht beliebig erweitern kann.
frontail nutzt die events.log und openhab.log Dateien, um die letzten 500(?) Zeilen pber Webfrontend zugänglich zu machen - incl. Filterfunktion, welche online funktioniert. Und natürlic hsteht einem über die Konsole die gesamte Historie zur Verfügung, welche gewöhnlich mehrere Tage oder sogar Wochen in die Vergangenheit reicht. openHAB packt die letzten logs immer in ein gz Archiv, es ist also einigermaßen kompakt, dafür muss man es aber zunächst entpacken, um darauf zuzugreifen. Das aktuelle log deckt stets die letzten Stunden ab, es sei denn, man hat ein grundsätzliches Problem auf dem System welches das log flutet ;) aber dann hilft die Itemliste auch nicht mehr...

Der Zugriff per App sollte auch funktionieren, es gibt sogar eine App (zumindest für Android) um direkt die logdateien anzuschauen (Logviewer for openHAB) - die setzt allerdings ebenfalls ein laufendes frontail voraus.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Antworten