Modul für ENIGMA2 Receiver

Begonnen von Loredo, 16 September 2013, 22:34:57

Vorheriges Thema - Nächstes Thema

DUSTiggr

Vielleicht verstehe ich dein Log nicht aber das ist doch ziemlich eindeutig. Intervall steht auf 30 Sekunden...

2016.01.07 14:35:42 5: Notify loop for VUplus input: tv
2016.01.07 14:36:12 5: Notify loop for VUplus input: radio
2016.01.07 14:36:42 5: Notify loop for VUplus input: tv
2016.01.07 14:37:12 5: Notify loop for VUplus input: radio


Ich habe keine Ahnung wie du die Auswertung machst, viel einfacher ist es "e2serviceaspect" von /web/about auszuwerten. Die Werte 0, N/A und 3 geben Aufschluss über die aktuelle Tätigkeit der VUBox und das sehr zuverlässig  ;)

Da es anscheinend kein Interesse an einem öffentlichen Bugfix gibt mache ich mich nun selber ans Werk die Funktion zu fixen.

BTW: Box gerade eingeschaltet und der Status flippt:


2016-01-08_16:55:54 VUplus input: radio
2016-01-08_16:56:23 VUplus input: tv
2016-01-08_16:56:53 VUplus input: radio
2016-01-08_16:57:23 VUplus input: tv
2016-01-08_16:57:53 VUplus input: radio
2016-01-08_16:58:23 VUplus input: tv
2016-01-08_16:58:53 VUplus input: radio
2016-01-08_16:59:23 VUplus input: tv
2016-01-08_16:59:53 VUplus input: radio
2016-01-08_17:00:23 VUplus input: tv
2016-01-08_17:00:53 VUplus input: radio
2016-01-08_17:01:23 VUplus input: tv
2016-01-08_17:01:53 VUplus input: radio
2016-01-08_17:02:23 VUplus input: tv
2016-01-08_17:02:53 VUplus input: radio
2016-01-08_17:03:23 VUplus input: tv

Loredo

Zitat von: DUSTiggr am 08 Januar 2016, 17:05:01
Vielleicht verstehe ich dein Log nicht aber das ist doch ziemlich eindeutig. Intervall steht auf 30 Sekunden...


Wenn du mehrere Intervalle geloggt hättest, wäre /getcurrent mehrfach zu finden. Ich kann es nur einmal finden.


Zitat von: DUSTiggr am 08 Januar 2016, 17:05:01
2016.01.07 14:35:42 5: Notify loop for VUplus input: tv
2016.01.07 14:36:12 5: Notify loop for VUplus input: radio
2016.01.07 14:36:42 5: Notify loop for VUplus input: tv
2016.01.07 14:37:12 5: Notify loop for VUplus input: radio



Zumindest laut deinem Logfile kommt das dann nicht vom ENIGMA2 Modul...


Zitat von: DUSTiggr am 08 Januar 2016, 17:05:01
Ich habe keine Ahnung wie du die Auswertung machst


Die Auswertung erfolgt durch Auswertung der servicereference, bei der die dritte Stelle ebenfalls die Serviceart angibt. 2 oder 10 entsprechen dabei Radio Streams.


Der Grund ist, dass ich mich aus Performancegründen (sowohl auf FHEM Seite, aber auch vor allem wegen schwachbrüstigen ENIGMA2 Boxen) entscheiden muss entweder /about oder /getcurrent regelmäßig abzufragen. /about liefert aber bei weitem nicht alle Infos, die ich sonst noch so brauche und deshalb müsste ich /about dann zusätzlich abfragen, was mir aber dann hauptsächlich redundante Informationen gibt. /about wird deshalb nur alle 15 Minuten abgefragt, um darüber ein paar Boxinfos zu bekommen, die sich nur sehr selten ändern (zB Model, MAC, Software Versionen, Festplatten, Tuner-Konfiguration). Über den aktuellen Sender bekomme ich darüber nicht alle Infos.


Zitat von: DUSTiggr am 08 Januar 2016, 17:05:01
viel einfacher ist es "e2serviceaspect" von /web/about auszuwerten. Die Werte 0, N/A und 3 geben Aufschluss über die aktuelle Tätigkeit der VUBox


In der API Spezifikation findet sich dazu keine offizielle Info, aus der das ersichtlich wäre, deshalb würde ich mich darauf nicht verlassen wenn es darum geht, möglichst alle Hersteller und Images zu unterstützen.


Zitat von: DUSTiggr am 08 Januar 2016, 17:05:01
Da es anscheinend kein Interesse an einem öffentlichen Bugfix gibt mache ich mich nun selber ans Werk die Funktion zu fixen.


Wie kommst du darauf?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DUSTiggr

Vielen Dank für deine ausführliche Antwort, ich kann nun vieles nachvollziehen.

ZitatWenn du mehrere Intervalle geloggt hättest, wäre /getcurrent mehrfach zu finden. Ich kann es nur einmal finden.
Wie gesagt FHEM ist noch relativ neu für mich, bin mir aber sehr sicher das sich dein Modul falsch verhält. Ich habe es bisher nicht geschafft nur das ENIGMA Modul mit verbose 5 zu loggen, hast du vielleicht einen Tipp für mich wie ich das Ganze eingrenzen kann? Ich lass das Log dann gerne auch Stunden laufen :)

Vorab habe ich daher die URL /web/getcurrent manuell im Browser aufgerufen und mehrere Minuten lang immer wieder aktualisiert, es ändern sich einige Laufzeitwerte aber nicht die Zeile <e2servicereference>1:0:2:6F41:44D:A401:FFFF0000:0:0:0:</e2servicereference> - Sofern die Box nicht genau zum Zeitpunkt der Abfrage Husten bekommt und sich plötzlich anders verhält können wir die Ausgabe der Box ausschließen, hier steht immer wie erwartet eine 2 an zweiter Position (TV eine 1).

ZitatIn der API Spezifikation findet sich dazu keine offizielle Info, aus der das ersichtlich wäre, deshalb würde ich mich darauf nicht verlassen wenn es darum geht, möglichst alle Hersteller und Images zu unterstützen.
Verständlich, ich habe meine Homematic Lösung durch experimentieren herausgefunden. Ich kann zumindest sagen für VTI 8.x, 9.x auf der Duo2 und Solo passen die Werte.  ;D

ZitatWie kommst du darauf?
Die vorherige Antwort habe ich wohl falsch verstanden, sorry.

Loredo

Zitat von: DUSTiggr am 08 Januar 2016, 18:13:52Ich habe es bisher nicht geschafft nur das ENIGMA Modul mit verbose 5 zu loggen, hast du vielleicht einen Tipp für mich wie ich das Ganze eingrenzen kann? Ich lass das Log dann gerne auch Stunden laufen :)


Du kannst das Attribut "verbose" auch nur beim ENIGMA2 Device setzen, dann wird nur für dieses Device das Logging hochgesetzt.


Zitat von: DUSTiggr am 08 Januar 2016, 18:13:52
Sofern die Box nicht genau zum Zeitpunkt der Abfrage Husten bekommt und sich plötzlich anders verhält können wir die Ausgabe der Box ausschließen, hier steht immer wie erwartet eine 2 an zweiter Position (TV eine 1).


Genau das kann man ja dann in einem ordentlichen Log sehen  ;)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DUSTiggr

Ich hoffe das passt nun so, falls nicht brauche ich eine Info was noch fehlt.

Loredo

Ich konnte da nichts finden (nur eine Kleinigkeit in der FHEMWEB Anzeige, die aber mit dem input nichts zu tun hat).
Ich habe gerade eine überarbeitete Version mit erweitertem Logging hochgeladen, vielleicht kann man es damit besser eingrenzen (oder es ist bei der Überarbeitung unwissentlich mit behoben).




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DUSTiggr

Ich habe soeben ein FHEM Update gemacht, da war keine neue Datei dabei.

Daraufhin habe ich die Datei aus dem GitRepo (erster Beitrag) gezogen und mit meiner aktuellen Datei per MD5 verglichen. Ein anschließendes diff zeigt massig viele Änderungen.

Das Plugin funktioniert nun 1a!!! 1000 Dank 8)

Zum Verständnis: Kann es sein das deine Updates überhaupt nicht per FHEM "update" ausgeliefert werden? Bzw ich die ganze Zeit eine veraltete Version genutzt habe?  :-[

Gruß,
Maik

Loredo

Immer erst am darauffolgenden Tag...
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Elektrolurch

Hallo,
seit dem letzten Update des Enigma-Moduls (muss so zwischen dem 7.1. und 10.1.2016  gewesen sein), wird für das reading "presence" das Attribut "event-on-change-reading .*" ignoriert.
Mein logfile wird jetzt mit Meldungen

Wz_Receiver presence absent
zugemüllt.

Wäre schön, wenn das korrigiert werden könnte.

Danke.

Elektrolurch
configDB und Windows befreite Zone!

Brice

Bei mir ist das ENIGMA-Modul am 31.12.2015 komplett ausgestiegen, d.h, die letzten Readings sind vom 31.12.2015. Verbose 5 bringt:
2016.01.11 17:35:25 5: ENIGMA2 SetTopBox: called function ENIGMA2_GetStatus()
2016.01.11 17:35:25 5: ENIGMA2 SetTopBox: called function ENIGMA2_SendCommand()
2016.01.11 17:35:25 5: ENIGMA2 SetTopBox: using unencrypted connection via HTTP
2016.01.11 17:35:25 4: ENIGMA2 SetTopBox: REQ powerstate
2016.01.11 17:35:25 5: ENIGMA2 SetTopBox: GET http://192.xxx.xxx.xx:80/web/powerstate (noshutdown=1)
2016.01.11 17:35:25 5: ENIGMA2 SetTopBox: called function ENIGMA2_ReceiveCommand()
2016.01.11 17:35:25 4: ENIGMA2 SetTopBox: RCV TIMEOUT powerstate


Auf meinem Testsystem, auf dem bisher keine SetTopBox definiert war, hatte ich diese heute definiert. Mit dem gleichen Resultat: Box hat permanent den State "absent".  Über das PRESENCE-Modul ist die Box "present".

FHEM update ist durchgeführt worden.

Wer hat eine Idee woran es liegen könnte?
FHEM auf RPi 4 4GB (Buster) | produktiv) CUL 868 für FS20 | S300TH | KS300 | Max!Cube als CUN 868 für TechemWZ | HM-MOD-RPI-PCB für HM | Z-Wave ZME_UZB1 | FRITZ!DECT 200 | HUE | Lightify | Echo Dot | WS3080

Loredo

#595
Zitat von: Brice am 11 Januar 2016, 17:44:56
Bei mir ist das ENIGMA-Modul am 31.12.2015 komplett ausgestiegen, d.h, die letzten Readings sind vom 31.12.2015. Verbose 5 bringt:
Wer hat eine Idee woran es liegen könnte?


Es handelt sich um einen Netzwerk Timeout. Das kann an der Netzwerkverbindung liegen oder aber am Image.
Ein Ping alleine sagt noch nicht, dass auf Port 80 (oder 443) auch ein Dienst antwortet (und dann noch der richtige...).


Zitat von: Elektrolurch am 11 Januar 2016, 16:43:34
Hallo,
seit dem letzten Update des Enigma-Moduls (muss so zwischen dem 7.1. und 10.1.2016  gewesen sein), wird für das reading "presence" das Attribut "event-on-change-reading .*" ignoriert.
Mein logfile wird jetzt mit Meldungen

Wz_Receiver presence absent
zugemüllt.

Wäre schön, wenn das korrigiert werden könnte.


event-on-*-reading ist eine FHEM interne Funktion. Das ENIGMA2 Modul verwendet ausschließlich die Funktion readingsBulkUpdate(), um die Readings zu schreiben. Aus ENIGMA2 Sicht kann nicht für ein einzelnes Reading unterbunden werden, dass das Attribut nicht beachtet wird. Deshalb kann ich hier auch nichts fixen, solange ich den Fehler nicht nachvollziehen kann.


Vielleicht schaust du dir erstmal das Logfile mit verbose=5 an. Oft kann man daraus die Ursache ersehen.
Wenn das Gerät häufig auf "offline" geht, dann bekommt FHEM nicht schnell genug eine Antwort von der Box. Das passiert zB bei langsamen/schwachbrüstigen Boxen oder wenn die Box gerade mit anderen Dingen beschäftigt ist (Streaming, Transcoding etc).
Für solche Fälle findest du in der Commandref eine Beschreibung zur Aktivierung des Lite-Modus für das ENGIMA2 Modul.


Übrigens: Eine solche Logausgabe wie von dir benannt erzeugt das Modul gar nicht. Ich denke mal du sprichst vom Eventlog. Dort wird aber nichts "vollgemüllt", es funktioniert wie designt.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Elektrolurch

Hallo,

Zitat:
Wenn das Gerät häufig auf "offline" geht, dann bekommt FHEM nicht schnell genug eine Antwort von der Box. Das passiert zB bei langsamen/schwachbrüstigen Boxen oder wenn die Box gerade mit anderen Dingen beschäftigt ist (Streaming, Transcoding etc).
Für solche Fälle findest du in der Commandref eine Beschreibung zur Aktivierung des Lite-Modus für das ENGIMA2 Modul.


Der Receiver war / ist ausgeschaltet. Bisher war das kein Problem. Seit dem Update kommen trotz ausgeschaltetem Receiver die events: Wz_Receiver present absent.
Die werden also gar nicht durch die Box generiert.

Zitat:
Übrigens: Eine solche Logausgabe wie von dir benannt erzeugt das Modul gar nicht.


Ja, das ist schon klar.
Also:
Ich habe mir ein Modul gebastelt, welches die Kombi aus einem Audiogerät (Sonos), einem Enigma2-Receiver und einer FS20 zum Ein- und Ausschalten verwaltet.
U.a. macht das Modul folgendes:
Wenn jemand per FB die Enigma-Box auf Standby setzt, dann wird der Eingang vom Sonos auf "intern" umgeschaltet und der letzte Radiosender gestartet.
Ein globales notify horcht auch auf die Events des Enigma, so u.a. auch auf
rd: present val: absent bzwe. present
Da kommt die Ausgabe her.
Seit dem letzten Update kommen nun aber trotz stromlos geschalteter VUPlus Box die event alle Intervall-Sekunden, dass die Box absent ist, obwohl event-on-change-reading .* gesetzt ist.
Jedesmal wird nun versucht, das Sonos-Gerät auf intern umzuschalten und den letzten Radiosender zu starten.
Ok. Als work-around frage ich jetzt ab, ob das Sonos überhaupt noch eingeschaltet ist, denn sendet man zu vile Befele an ausgeschaltete Sonos-Geräte, hängen sich die Prozesse vom Sonos-Modul auf.

Die Frage, die sich mir stellt, ist: Warum kommen nun trotz gesetztem event-on-change-reading .* gleiche Ereignisse mit gleichen Werten? (seit dem letzten Update vor  einigen Tagen)
Mein Modul in der o.g. Funktionalität  läuft jetzt seit Monaten ohne Probleme.

Im übrigen: nonblocking - calls scheinen sich ja auch geändert zu haben. Ev. kommt daher der Effekt, weil ja keine VUPlus - Box mehr erreichbar ist.

Elektrolurch


Elektrolurch
configDB und Windows befreite Zone!

Brice

Danke Loredo, lag wohl an einer Aktualisierung des Image meiner VU+ Uno. Nach Neuaufsetzen mit dem VTI 9.0-Image funktioniert es wieder. Die Aktualisierungen lass ich erst mal bleiben...
FHEM auf RPi 4 4GB (Buster) | produktiv) CUL 868 für FS20 | S300TH | KS300 | Max!Cube als CUN 868 für TechemWZ | HM-MOD-RPI-PCB für HM | Z-Wave ZME_UZB1 | FRITZ!DECT 200 | HUE | Lightify | Echo Dot | WS3080

hilde

#598
Ich habe auch das Phänomen mit den ständigen presence Log Einträgen.

Dabei ist mir aufgefallen, dass bei mir seit dem letzten Update immer zwei unterschiedliche Log Einträge nacheinander für presence erzeugt werden - einmal ohne Wert und einmal mit dem Wert absent. Das könnte erklären weshalb event-on-change-reading nicht funktioniert wie erwartet, denn tatsächlich ändert sich das Readings ja auch jedesmal.

Das sieht bei mir zum Beispiel aktuell so aus:

2016-01-14_18:48:52 Wohnzimmer_Dreambox presence:
2016-01-14_18:48:52 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:49:37 Wohnzimmer_Dreambox presence:
2016-01-14_18:49:37 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:50:22 Wohnzimmer_Dreambox presence:
2016-01-14_18:50:22 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:51:07 Wohnzimmer_Dreambox presence:
2016-01-14_18:51:07 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:51:52 Wohnzimmer_Dreambox presence:
2016-01-14_18:51:52 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:52:37 Wohnzimmer_Dreambox presence:
2016-01-14_18:52:37 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:53:22 Wohnzimmer_Dreambox presence:
2016-01-14_18:53:22 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:54:07 Wohnzimmer_Dreambox presence:
2016-01-14_18:54:07 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:54:52 Wohnzimmer_Dreambox presence:
2016-01-14_18:54:52 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:55:37 Wohnzimmer_Dreambox presence:
2016-01-14_18:55:37 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:56:22 Wohnzimmer_Dreambox presence:
2016-01-14_18:56:22 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:57:07 Wohnzimmer_Dreambox presence:
2016-01-14_18:57:07 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:57:52 Wohnzimmer_Dreambox presence:
2016-01-14_18:57:52 Wohnzimmer_Dreambox presence: absent
2016-01-14_18:58:37 Wohnzimmer_Dreambox presence:
2016-01-14_18:58:37 Wohnzimmer_Dreambox presence: absent


Im Grunde stört mich das nicht weiter, sorgt bei mir allerdings dafür, dass meine darauf basierenden SVG Graphen das fhem Logfile voll schreiben mit einer großen Menge folgender Meldungen:

2016.01.14 14:54:59 3: eval: $fld[3]=~"present"?1:0
2016.01.14 14:54:59 1: PERL WARNING: Use of uninitialized value $fld[3] in pattern match (m//) at (eval 84682) line 1, <GEN104231> line 4639.


Update/Edit:
Ich habe mich jetzt mal in dem Modul nach Updates des presence Readings umgesehen und würde tippen, dass das Phänomen von diesem Block (speziell der if Clause) ab Zeile 1004 verursacht wird. Allerdings habe ich zu wenig Plan von Perl und von dem Modul, um das wirklich genau zu sagen. Aber vielleicht hilft's ja bei der Lösung.

            $presence = "absent";
            readingsBulkUpdate( $hash, "presence", $presence )
              if ( readingsBulkUpdate( $hash, "presence", "" ) ne $presence );

Loredo

Danke, da hatte ich wohl Tomaten auf den Augen. Habs geändert und eingecheckt.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER