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

[HCS]

Hallo!

Ich bekommen mit dem Treiber leider keine Verbindung zu stande. Port hab ich auf 2121.  Auch nach einem FHEM Neustart bleibt das fronthemdevice auf disconnected. Nach dem zurückstellen auf domotiga passt wieder alles.
Hast du eine Idee?

Grüße

Hast Du nach dem Umstellen auf den FHEM-Treiber auch die IP-Adresse wieder eingetragen?

[fhainz]

Die IP Adresse bleibt bei mir in dem Feld stehen, hab sie aber zur Sicherheit nochmals eingegeben. Kein Erfolg.

[HCS]

Mach mal im browser mit F12 die Konsole auf, mach danach einen page reload mit F5 und schau, ob Einträge, die mit [io.fhem] beginnen, geloggt werden.

[fhainz]

Code Auswählen Erweitern

[Error] Failed to load resource: the server responded with a status of 404 (Not Found) (io_fhem.js, line 0)
Kommt bei mir in der JS-Konsole.

Nachdem ich die Datei umbenannt hab, klappt es.

[bgewehr]

nur wenn der config.ini Parameter auf .min.js steht, wird der neue fhem Treiber gefunden. Wenn er auf .js steht, muss auch der Treiber als .js vorhanden sein. Also datei kopieren, einmal als min.js, einmal als .js, dann mûsste es bei jedem gehen..


Gesendet von meinem iPad mit Tapatalk

[chris1284]

genau so funktionierte es auch erst bei mit. treiber dublizieren so das es ihn einmal mit und einmla ohne min gibt. nur umbennen half nicht da er dann nicht in der liste der treiber auftaucht

[marvin78]

Der Treiber ist ohnehin keine "min" Das täuscht hier etwas.

[HCS]

Der Treiber ist ohnehin keine "min" Das täuscht hier etwas.

Ja klar. Wollte ich mir sparen, bis er irgendwie amtlich wird.
Und sorry Leute, dass jemand nicht min konfiguriert hat, war mir völlig aus dem focus gefallen.
Ich ändere gleich mal meinen originalen post dass nicht noch mehr drauf reinfallen.

[herrmannj]

Hi HCS,

sehr coole Idee !

Ich habe zwar schon prototyp Varianten von erweitertem js hier rumliegen, wenn Du die Vaterschaft über den driver übernehmen möchtest finde ich das sehr gut.

Wenn ich mir Vorschläge erlauben darf: ich würde den Timer primär an die "onclose" und "onerror" events des websockets binden und den dialog erst nach 2-3 Fehlversuchen anzeigen. *edit

Bzgl der vielen GADs und dem folgenden blocking bin ich mal testweise jquery Queue gegangen, das scheint gut zu funktionieren weil asynchron. Dazu müsste man den "onmessage" Zweige (mMn für items und series) darüber routen. Kann ich sehr gern unterstützen.

Ein dritter block: ich habe vereinzelt beobachtet (hauptsächlich android, IOS meldet sich bei mir sehr zuverlässig ab) das ein Tab in den standby geht ohne den ws abzuschalten, sondern den einfach einfriert. Hier müsste man ggf nochmal genau untersuchen um zu verhindern das während der ws "eingefroren" ist einzelne Nachrichten verloren gehen. Das ist aber nur Rand-Prio, normal puffert fronthem. Vielleicht einfach im Hinterkopf behalten.

Und last but not least: die vorhandene Webviecontrol von Dirk läßt sich nicht (nur sehr umständlich und sehr benutzer-unfreundlich) für fronthem/sv benutzen, zumindest in Bezug auf tts, brightness, play etc. Da bin ich dabei eine Variante zu erstellen die das voll unterstützt. Der Plan ist das die device Funktionen von der App automatisch als GAD zur Verfügung gestellt werden und das fronthem device einen Erweiterungssatz dazu genauso selbstständig nach-lädt. Da kann es sein das der Treiber zumindest minimal irgendwas dazu beitragen muss, bspw das dialoge (als Benachrichtigungen von fronthem) als Nachricht in android auch dann angezeigt werden, sollte die app im Hintergrund laufen. Kann ich aber noch nicht genau sagen wie - sehen wir dann.

vg
jörg

[HCS]

Wenn ich mir Vorschläge erlauben darf

Natürlich.

ich würde den Timer primär an die "onclose" und "onerror" events des websockets binden

Ja, das ist sinnvoller als ihn ständig kreisen zu lassen. Werde ich in die Richtung lenken.
Ich wollte erst mal schnell und ohne viel Aufwand sehen, ob das generell so hilft.

wenn Du die Vaterschaft über den driver übernehmen möchtest finde ich das sehr gut.

So schnell kommt man zu Nachwuchs
Soweit es mir möglich ist, mache ich das mal.

... und den dialog erst nach 2-3 Fehlversuchen anzeigen

Warum hast Du die Idee wieder verworfen? Fand ich spontan sinnvoll.

Und last but not least: die vorhandene Webviecontrol von Dirk läßt sich nicht (nur sehr umständlich und sehr benutzer-unfreundlich) für fronthem/sv benutzen, zumindest in Bezug auf tts, brightness, play etc. Da bin ich dabei eine Variante zu erstellen die das voll unterstützt. Der Plan ist das die device Funktionen von der App automatisch als GAD zur Verfügung gestellt werden und das fronthem device einen Erweiterungssatz dazu genauso selbstständig nach-lädt. Da kann es sein das der Treiber zumindest minimal irgendwas dazu beitragen muss, bspw das dialoge (als Benachrichtigungen von fronthem) als Nachricht in android auch dann angezeigt werden, sollte die app im Hintergrund laufen. Kann ich aber noch nicht genau sagen wie - sehen wir dann.

OK, das würde dann den pageReload vom fronthemDevice unnötig machen.
Der würde aber trotzdem nicht schaden, für jemanden, der das (alte oder neue) WVC nicht einsetzten kann oder will.

Wenn Du noch Treiber-Experimente rumliegen hast, kannst Du sie mir ja mal schicken.

[bgewehr]

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?

Hallo Bernd,

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

Kann ich hier mglw. am Converter helfen? Was würde denn gebraucht?

EDIT:

Aktueller flow:

Code Auswählen Erweitern


[io.fhem] sending data: {"cmd":"item","id":"EG_blind_uzsu","val":{"active":true,"list":[{"active":false,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","time":"00:00","value":0}]}}
io_fhem.min.js:1 [io.fhem] receiving data: {"cmd":"item","items":["EG_blind_uzsu","HASH(0x364c740)"]}
io_fhem.min.js:1 [io.fhem]: update item: EG_blind_uzsu val: HASH(0x364c740)


[herrmannj]

So schnell kommt man zu Nachwuchs

Warum hast Du die Idee wieder verworfen? Fand ich spontan sinnvoll.

Mach nach Lust und Laune, ich hab erst mit Verzögerung geschnallt das Du mit "gelb" - "rot" schon Stufen drin hast.

OK, das würde dann den pageReload vom fronthemDevice unnötig machen.

Lass gern drin, frist ja kein Brot.

Wenn Du noch Treiber-Experimente rumliegen hast, kannst Du sie mir ja mal schicken.

Das muss neu aufgebaut werden. In so einem Experiment sind xx Irrwege drin und 1 einer der dann klappt. Ohne Wissen welche (warum) macht das keinen Sinn. Daher lieber theoretisch, hier die api zu jquery queue http://api.jquery.com/queue/

Ich hab den Post hier nicht mehr parat aber ich hatte das mal so überschlagen: wir sprachen, glaub ich, über >300Gad mit ca 6-7sek. Da landet man bei ~25ms pro Gad. An sich wenig spektakulär, die Summe macht es aber. Wenn da später noch series (plots) dazukommen dann wird das schon ein echtes Thema. Wie kommt die Zeit zustande ? Vmtl braucht jquery die einfach weil es über die Selektoren für jedes GAD erstmal den ganzen DOM scannen muss um das widget zu finden.

Die Idee ist also eine jquery queue im Treiber einzurichten. Das schreiben (aus "onmessage") in die Queue müsste also zeit optimiert ablaufen. Am Ausgang der queue für dann das jeweilige "widget.update(item, val);" aufgerufen - jquery selber trägt Sorge für den asynchronen Aufruf und auch dafür das sv die gesamte Zeit trotzdem responsive bleibt. Ich vermute das sich bei +300Gads auch die overhead Zeiten bemerkbar machen, um initial alle GADs zu laden dauert es dann also vmtl länger als 7 Sekunden - mit dem Unterschied das sv schon bedienbar ist.

Das aber bitte nur als Vorschlag, wenn Du andere Ideen hast gerne rin damit 

vg
jörg

[herrmannj]

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?

Kann ich hier mglw. am Converter helfen? Was würde denn gebraucht?

EDIT:

Aktueller flow:

Code Auswählen Erweitern


[io.fhem] sending data: {"cmd":"item","id":"EG_blind_uzsu","val":{"active":true,"list":[{"active":false,"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE","time":"00:00","value":0}]}}
io_fhem.min.js:1 [io.fhem] receiving data: {"cmd":"item","items":["EG_blind_uzsu","HASH(0x364c740)"]}
io_fhem.min.js:1 [io.fhem]: update item: EG_blind_uzsu val: HASH(0x364c740)


Hi Bernd,

völlig richtig, das war so zu sagen nur der Machbarkeitstest. Ich befürchte aber da kannst Du nur wenig tun. Bei der uzsu ist der converter nicht ein add-on sondern integraler Bestandteil im Modul. Andre wartet da auch bestimmt schon, er hat entsprechende widgets für fhem schon gebaut.  Ich schau mal das ich da so schnell als möglich beigehen kann - aber das "richtige Leben" gibt es halt auch noch. Will (muss) halt auch Geld mit bezahlter Arbeit verdienen ...

vg
jörg

[bgewehr]

Kannst Du die Architektur aus Deinem Kopf hier mal kurz rauslassen?


Gesendet von iPhone mit Tapatalk

[herrmannj]

btw, ich mach nochmal ein update im GIT mit den fix für das Prob von Olli - dann mach ich (morgen?) hier zu und mach einen neuen thread mit bugs und wünschen zu fronthem auf. Wir hatten das ja schon einige Male, HCS vorhin auch - völlig richtig: hier verlieren wir Infos.

vg
jörg