erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[bgewehr]

Zum Thema UZSU: ich habe Deinen Vorschlag umgesetzt, Jörg, aber SV kann damit zwar erfolgreich die Daten an fhem schreiben, aber nicht wieder lesen, beim zweiten Aufruf ist die UZSU wieder leer! Ist das bei Dir auch so?


Gesendet von iPhone mit Tapatalk

[herrmannj]

Hallo Bernd,

ja, nur demo wegen converter - das ist in der demo one way.

vg
jörg

[avg123-de]

mit Sicherheit wurde die Frage in dem 55 Seiten langen Thread schon gestellt, aber an welcher Stelle kann ich denn aktiv etwas editieren? Wo finde ich diese GAD`s 

Ich habe auf meine mac mini

- einen Apache installiert, dort wie im wiki beschrieben Smartvisu installiert, welches auch mit der korrekten Startseite erscheint.

- Die notwendigen Perl Module installiert

- fronthem per update force installiert

- fronthem definiert STATE

- fronthemDevice für ein iPad und ein MBP definiert

Gehe ich mit den Clients auf http://server/smartvisu/index.php wird in FHEM auch brav connected bei den Clients angezeigt

Aber an welcher Stelle kann ich jetzt Dinge mit einem Editor bearbeiten?

Eine config.ini habe ich z.B. nach meiner Installation nicht im Hauptverzeichnis von sv gefunden, dass manuelle anlegen und füllen mit Angaben, welche ich am Anfang des Threads gefunden habe:

Code Auswählen Erweitern

[clients]
10.0.81.254 = 'iPad'
10.0.81.248 = 'mbp'
[client:iPad]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'
[client:mbp]
title = 'Fhem'
cache = false
animation = false
driver_realtime = true
pages = 'fhem'
design = 'night'
driver_address = '10.0.81.60'

hat keinen Effekt auf den Eingangsbildschirm den meine Clients beim verbinden mit sv haben. (dort wird weiterhin ein Demo Haus angezeigt)

Greetz
Eldrik

Hallo,

einfach auf das jeweilige fronthemDevice in FHEM klicken, dann werden oben, sofern in SmartVisu definiert die GADs angezeigt.

viele Grüße
Alexander

[eldrik]

Hallo Alexander,

danke für die Rückmeldung!

Ich habe heute noch ein paar Tests durchgeführt, was aufgefallen ist, als ich gestern um 23:30 die Augen geschlossen habe hat sich Fhem um ca. 01:14 ohne Meldung im Log weggehangen, so dass ich es heute früh erst einmal wieder starten musste und alle Definitionen fronthem betreffend sicherheitshalber entfernt habe.

Als ich wieder aktiv vor einem Rechner saß habe ich wieder die Definitionen vorgenommen und weiter mit fronthem experimentiert, Fhem hat sich dann noch einmal ohne Meldung im Log beendet!

Daraufhin habe ich Fhem via update aktualisiert (hatte ich die Tage bewusst nicht gemacht wegen der vielen gemeldeten Fehler, im Zusammenhang, mit dem JS Umbau).

Nach dem Update waren in den fronthemDevice Einträgen auch erstmalig oben die Tabelle mit:

gad device r w

zu sehen.

Ferner habe ich mir nun die smartvisu pages von bgewehr aus dem github geladen und erfolgreich gads aufgelistet bekommen, mit denen ich jetzt auch erfolgreich testen konnte

Ich hoffe, dass Fhem nach dem letzten Update auch stabil läuft und nicht im Zusammenhang mit fronthem abschmiert.

Greetz
Eldrik

[marvin78]

Ich hatte leider mir der aktuellen fronthem Version (update force) gestern wieder einen kommentarlosen Absturz von FHEM. Szenario war Aktualisierung der SmartVisu Seite im Chrome. Etwa die Hälfte der gads wurden geladen, der Rest nicht. Also ist FHEM während des Ladens der Seite abeschmiert. Kein anderes Device außer dem Laptop im LAN war zu der zeit mit Fronthem verbunden, es war also kein Standby oder Flugmodus Problem.

[ftobi]

Hallo,

ich habe auch grade den Steuerungsrechner ohne fhem-Prozess gefunden.
Letzte bekannte Aktion zu der Uhrzeit war, dass meine Frau mit Ihrem Handy (Android mit Chrome, als device mit connect) ungefähr zu der Uhrzeit das Haus verlassen hat.

Letzter relevanter Eintrag im fhem.log:

Code Auswählen Erweitern

2015.01.14 08:30:45 1: gui: thread ws closed for unknown reason

Im access.log von apache2 hab ich den letzten Zugriff allerdings schon um 08:08:53 Uhr. error.log ist nichts drin

Grüße

[herrmannj]

Tja, und ich dachte ich könnte mich wieder hinlegen ...

Zur Sicherheit: bei allen aktuelle Version (fhwebsocket)? (Gleiche Größe wie im git? Wichtig, weil ich hatte diesbezüglich was gefixt). Bitte schaut mal im fhem Verzeichnisse ob in der Frontem.err was drinsteht.

Vg
Jörg

[ftobi]

Hallo Jörg,

fronthem.err:

Code Auswählen Erweitern

send: Cannot determine peer address at /opt/fhem/FHEM/01_fronthem.pm line 674.
Die hat aber ein File-Datum Jan 12 21:31, also anderer Zeitpunkt.

Hatte aber die letzten Änderungen in fhmwebsocket.pm nicht drin (die Klammer in Zeile 159 aus dem letzten change). Hab geupdatet und neu gestartet.

Grüße

[avg123-de]

Hallo zusammen,

habe heute mal wieder das Update von fronthem über

Code Auswählen Erweitern


update force https://raw.githubusercontent.com/herrmannj/fronthem/master/controls_fronthem.txt

durchgeführt, jedoch werden mir meine GADs in FHEM nicht mehr angezeigt, in den Dateien sind sie jedoch noch vorhanden und das Schalten über sv von Aktoren und das Anzeigen von Werten aus FHEM klappt soweit noch einwandfrei.
Nur kann ich so leider auf den GAD-Editor zugreifen um neue Devices anzulegen, bzw. zu bearbeiten.

viele Grüße
Alexander


EDIT: Sorry, hat sich erledigt, hatte vergessen ein FHEM-Update durchzuführen   

[marvin78]

Tja, und ich dachte ich könnte mich wieder hinlegen ...

Zur Sicherheit: bei allen aktuelle Version (fhwebsocket)? (Gleiche Größe wie im git? Wichtig, weil ich hatte diesbezüglich was gefixt). Bitte schaut mal im fhem Verzeichnisse ob in der Frontem.err was drinsteht.

Vg
Jörg

Selbe größe, selbe Version. Die err Datei ist leer, deshalb "Kommentarlos" Sorry, mehr Anhaltspunkte kann ich nicht geben, werde das aber weiter beobachten.

[ftobi]

Hallo Jörg,

folgendes kann ich jetzt reproduzieren:
- smartVisu Oberfläche reagiert normal und aktualisiert die Werte.
- Bei geöffnetem Firefox Notebookdeckel zu, 30 Minuten warten. Dann wieder öffnen.
- Ab hier "Could not connect to DomotiGa server!". Keine Daten mehr. Reload der Seite per F5 geht auch nicht.

Meldung im fhem-log:

Code Auswählen Erweitern

2015.01.14 22:07:07 1: gui: thread ws closed for unknown reason
Sonst keine fehler, auch nicht im fronthem.err. fhem isoliert läuft und reagiert, aber es gibt einen fhem-thread weniger.

voher:

Code Auswählen Erweitern

linaro@cubietruck:~$ ps -ax | grep fhem
3412 pts/0    S      0:32 perl fhem.pl fhem.cfg
3423 ?        Ss     0:01 perl fhem.pl fhem.cfg
3823 pts/0    S+     0:00 grep --color=auto fhem

nachher:

Code Auswählen Erweitern

linaro@cubietruck:~$ ps -ax | grep fhem
3412 pts/0    S      0:49 perl fhem.pl fhem.cfg
4394 pts/0    S+     0:00 grep --color=auto fhem

Mehr hab ich nicht finden können, hoffe es hilft.
Grüße
Tobi

[herrmannj]

Hallo

und vielen Dank für die guten Berichte. Bin unterwegs gewesen und komme erst jetzt zur ausführlicheren Antwort.

Der Komplettausstieg von fhem ist bedauerlich (sorry!) - aber kein Mysterium. Der Websocket läuft in einem thread und an der Stelle im Haupt modul wo, nach einem Fehler, erst aufgeräumt werden soll und der ws danach neu gestartet steht aktuell nur "#TODO". In der alpha gab es keine Probleme mit dem ws und daher auch keine Prio das sofort einzubauen. Diesen Block baue ich morgen ein. Damit braucht auch keine Angst zu bestehen das der ws das komplette System mit nimmt.

Teil zwei kann ich anhand der Beschreibung recht sicher im writepuffer verorten. Dafür war das letzte update. Den Test mit Deckel zu, 30min warten, wieder auf habe ich in dem Zusammenhang mehrfach fehlerfrei durchgeführt. Das bedeutet nun das es Sondersituationen (System oder Timing) gibt wo das nicht vollständig greift.

Da mir klar ist WAS passiert werde ich das WARUM auch zeitnah finden. Nochmal Danke für die reports - damit kann ich gut arbeiten. Viel mehr könnt ihr von nicht machen, höchsten ein Auge auf fronthem.err haben, falls noch weitere Meldungen auflaufen.

vg
jörg

[eldrik]

Hi,

heute ist fhem wieder stehen geblieben, letzte Meldungen im Log:

Code Auswählen Erweitern

2015.01.15 14:18:22.080 5: ipc fronthem:127.0.0.1:49275 (ws): receive {"log":{"cmd":"log","level":4,"text":"ws send to client{\"items\":[\"VZ.strom.aktuell\",\"677.5\"],\"cmd\":\"item\"}"}}
2015.01.15 14:18:22.081 4: ipc fronthem:127.0.0.1:49275 (ws): ws send to client{"items":["VZ.strom.aktuell","677.5"],"cmd":"item"}

Es wurde auch nichts in fronthem.err und .out

Ich war zu dem Zeitpunkt nicht aktiv an dem System, der Browser mit sv war auf einem Client im Hintergrund geöffnet.

Greetz
Eldrik

[herrmannj]

super - Danke.

Ich habe den Fehler mittlerweile auch eindeutig identifizieren können - keine Magie, keine Esoterik - ich habe einen Fehler in der Umsetzung der Puffer Logik. Das update folgt asap.

Danke und viele Grüße
Jörg

[Jojo11]

Das klingt sehr gut! Dann mache ich auch noch mal den Stabilitätstest

schöne Grüße
Jo