(gelöst) Kein automatisches Updaten der Oberfläche bei Statusänderung

[ThomasRamm]

Hallo,
Wenn sich der Status eines meiner Geräte ändert wird dies nicht automatisch auf der weboberfläche angezeigt.
Erst nach einem Refresh der Seite wird der Status aktualisiert.
Kann mir jemand sagen wo ich diesbezüglich ansetzen kann?

Es handelt sich um ein von mir selbst geschriebenes 2-stufiges Modul.
http://forum.fhem.de/index.php/topic,27577.msg204858.html#msg204858

Der Status wird per readingsSingleUpdate($n, "state", $ValueTranslated, 1); geändert.
Habe auch schon readingsSingleUpdate($n, "state", $ValueTranslated, 0); ohne Erfolge versucht.

Gruß
Thomas

[franky08]

Hallo, longpoll auf 1?

VG
Frank

[ThomasRamm]

longpoll hatte ich nicht gesetzt.
Ein Setzen auf 1 oder 0 ändert aber leider nichts.

[rudolfkoenig]

Prinzipiell zeigt FHEMWEB Aenderungen an, wenn diese per Event vom Modul bekanntgegeben werden.

Um readings per Event bekanntzugeben, muss bei readingsSingleUpdate bzw readingsEndUpdate das letzte Parameter ($dotrigger) wahr (1) sein. Ob das funktioniert, prueft man am besten in der Telnet Verbindung mit gesetzten inform timer (siehe auch Doku), da ueber FHEMWEB mehr schiefgehen kann.

Fuer das automatische aktualisieren in FHEMWEB muss das Attribut longpoll auf 1 sein (default!), und JavaScript darf nicht blockiert sein. Es gibt div. Probleme mit IE (mir unklar was genau tut oder nicht) und iOS8 (die ich nicht reproduzieren kann).
Auch in FHEMWEB sollte man zunaechst im Event-Monitor pruefen ob die Events ankommen, um die Problemstelle einzugrenzen.

[rudolfkoenig]

@8PABenny, dir sollte Klar sein, dass
- das nicht hierher gehoert, weil es mit dem urspruenglichen Thema nichts zu tun hat
- ich mit sochen Fehlermeldungen nix anfangen kann, weil bei mir alles funktioniert.

Wenn Leute sich nicht die Zeit nehmen, bei einem kostenlosen Software dem Entwickler zu helfen, ein Problem zu lokalisieren, dann senkt das die Motivation ueberhaupt an dem Projekt mitzuarbeiten, erheblich. Aber vielleicht ist das auch das Ziel dieser Leute.

[rudolfkoenig]

Das Projekt lebt nicht von ungenauen Fehlermeldungen, sowas schreckt nur neue Neulinge ab, die nicht erkennen, dass es nur ein Sonderfall ist. Das Projekt lebt von neuen Modulen, Fehlerkorrekturen, Dokumentation und Loesungsbeschreibungen.

Und wenn man selbst nicht Programmieren kann oder will, dann sollte man bei Problemmeldung die Zeit nehmen, und das Problem so genau beschreiben, dass der Entwickler seine fuer FHEM geopferte Zeit nicht mit raten und probieren verbringt, sondern mit der Fehlerbehebung. Mag sein, dass wir fuer manche als Allwissende erscheinen, sind wir aber nicht.

[ThomasRamm]

telnet-Verbindung und Event-Monitor zeigen leider nichts an.

Ich habe aktuell ein weiteres Modul "Presence" laufen das alle 2 Minuten prüft ob mein Handy im WLAN ist.
Von diesem Modul kommen sowohl im telnet als auch im Event-Monitor die Events an.

Wenn ich mein Licht über einen Separaten PC per FHEM Weboberfläche schalte, kommen die Events ebenfalls an und werden mir angezeigt.
Schalte ich das Licht aber über den Lichtschalter wird der Status nicht aktualisiert.

Ein Auszug aus dem Event-Monitor:
2014-10-04 15:35:07 S5_Digital wohn.licht1 off (geschaltet per FHEM)
2014-10-04 15:36:24 PRESENCE Nexus5 present
2014-10-04 15:38:27 PRESENCE Nexus5 present

Vielleicht noch ein Hinweis zu meiner ganzen Programmlogik (wird ja wohl am wahrscheinlichsten daran liegen):
das Physikalische Modul S5 wird alle 2 sekunden aufgerufen (S5_GetUpdate) und liest den Status aller Ausgänge.
per Dispatch wird der gelesene String an das logische Modul S5_Digital übergeben.
Die Funktion S5_Digital_Parse sucht nach entsprechenden Modulen und setzt den neuen Status sofern er sich verändert hat mit readingsSingleUpdate($n, "state", $ValueTranslated, 1);

Der neue Status wird mir in der Oberfläche an zwei Stellen angezeigt:
Internals -> STATE = on
Readings -> state =on (inkl. Uhrzeit der letzten Änderung)

[rudolfkoenig]

Liefert Parse den Namen des betroffenen Geraetes an Dispatch zurueck?

[ThomasRamm]

ja, ich fülle eine Liste aller Geräte mit

push(@list, $n);
return @list;

wobei $n = $modules{S5_Digital}{defptr}{$ID};

ein Auszug aus Dumper(@list):

Code Auswählen Erweitern

$VAR2 = {
          'DB' => '5',
          'NAME' => 'kueche.licht3',
          'READINGS' => {
                          'state' => {
                                       'TIME' => '2014-10-04 13:24:17',
                                       'VAL' => 'off'
                                     }
                        },
          'DEF' => 'db 5 66',
          'CODE' => 'db.5.66',
          'TYPE' => 'S5_Digital',
          'AREA' => 'db',
          'IODev' => $VAR1->{'IODev'},
          'POSITION' => 66,
          'NR' => 87,
          'STATE' => 'off'
        };
$VAR3 = {


[rudolfkoenig]

Kannst Du ein Auschnitt aus dem log mit loglevel 5 hier posten?
Man kann Dispatch aus telnet mit

Code Auswählen Erweitern

{ Dispatch($defs{IODEVNAME}, "RAWMSG_FUER_PARSE", undef) }
aufrufen, und so die Routinen auch ohne angeschlossenes Geraet debuggen.
Vorher noch inform timer im telnet setzen, und dann sieht man direkt die verdauten Events, die versendet werden. Wenn es funktioniert

Also falls nix klappt, dann poste dein Modul, und ein RAWMSG, und ich versuche selbst nachzuschauen.

[ThomasRamm]

Hier meine Log-Datei von zwei Lesezyklen. im zweiten Zyklus habe ich ein Licht ausgeschaltet.
Was mir auffällt ist das trotz debuglevel 5 Ausschließlich die Meldungen von meinem eigenen Modul angezeigt werden. Ist das so korrekt?
In der config Datei ist angegeben
attr global verbose 5

Ich habe das Logging so aufgebaut das beim Aufruf einer Funktion diese sich selbst mit ">> Funktionsname" logt, als vorletzte Zeile vor dem Return mit "<< Funktionsname" das Ende der Funktion ausgibt.

Code Auswählen Erweitern

2014.10.04 17:12:38 4: S5 >> S5_GetUpdate
2014.10.04 17:12:38 4: read Bytes FromPLC:132,5,9,1 (Bits:73-74)
2014.10.04 17:12:38 4: S5 >> S5_NodaveReadBytes
2014.10.04 17:12:39 5: LIBNODAVE LIEST: 0:01101110 (5.9)
2014.10.04 17:12:39 4: S5 << S5_NodaveReadBytes
2014.10.04 17:12:39 5: mysps dispatch S5_d db 5 73 01101110
2014.10.04 17:12:39 4: S5_Digital >> Parse
2014.10.04 17:12:39 5: db.5.73 Status ist bereits off
2014.10.04 17:12:39 5: db.5.74 Status ist bereits on
2014.10.04 17:12:39 4: S5_Digital << Parse
2014.10.04 17:12:39 4: S5 << S5_GetUpdate

2014.10.04 17:12:44 4: S5 >> S5_GetUpdate
2014.10.04 17:12:44 4: read Bytes FromPLC:132,5,9,1 (Bits:73-74)
2014.10.04 17:12:44 4: S5 >> S5_NodaveReadBytes
2014.10.04 17:12:44 5: LIBNODAVE LIEST: 0:00101110 (5.9)
2014.10.04 17:12:44 4: S5 << S5_NodaveReadBytes
2014.10.04 17:12:44 5: mysps dispatch S5_d db 5 73 00101110
2014.10.04 17:12:44 4: S5_Digital >> Parse
2014.10.04 17:12:44 5: db.5.73 Status ist bereits off
2014.10.04 17:12:44 4: Update Status:db.5.74 = off
2014.10.04 17:12:44 4: S5_Digital << Parse
2014.10.04 17:12:44 4: S5 << S5_GetUpdate


Code Auswählen Erweitern


inform timer
{ Dispatch($defs{mysps}, "S5_d db 5 73 01101110", undef) }
bringt mir als Rückmeldung sofort: ARRAY(0xd36930) mit dem ich aber nichts anfangen kann

mit inform raw sehe ich die 5sec. Intervallaufrufe des Dispatcher

Code Auswählen Erweitern

S5 mysps S5_d db 5 73 00101110
S5 mysps S5_d db 5 73 00101110
S5 mysps S5_d db 5 73 00101110
S5 mysps S5_d db 5 73 00101110

Das Modul selber habe ich hier hochgeladen: http://forum.fhem.de/index.php/topic,27577.0.html

[rudolfkoenig]

Parse muss eine Liste der gefundenen Namen zurueckliefern, nicht eine $hash Liste

Weitere Bemerkungen:
- Falls Nodave::daveReadBytes sich verklemmt, dann klemmt FHEM. Das kann man leider z.zt. nur kompliziert umgehen: entweder durch vorgeschaltetes select (weiss nicht ob Nodave sowas unterstuetzt), oder durch auslagern der Leseroutine via FHEM-BlockingFn (das ist nicht ganz ausgereift). Da ich keine schnelle/gute Loesung habe, ist das wirklich nur als Hinweis zu sehen.
- Falls man im logischen Modul auf irgendetwas in IODev zugreift, dann ist das Modul nicht FHEM2FHEM faehig. Die "erlaubten" Methoden fuer die Kommunikation zwischen den beiden Modulen ist IOWrite und Dispatch, falls man FHEM2FHEM verwenden will.

[ThomasRamm]

Vielen Dank für deine Hilfe,
ich glaube da wäre ich sonst nie drauf gekommen.

habe push(@list, $n); in push(@list, $n->{NAME}); geändert, jetzt funktioniert die aktualisierung.

Die anderen Punkte schaue ich mir auch noch an und aktualisiere dann das Modul.

Vielen Dank
Thomas