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

[herrmannj]

@Jörg: Ich habe aktuell geschafft, das UZSU-Widget mit einem Reading uzsu eines fhem device zu verbinden, so dass die Speicherung der JSON-Information zum Widget erledigt wäre. Ich nutze dazu einen setreading-converter, der eine regex-replace macht ';' -> ';;' weil sonst fhem den String nach dem ersten ';' abschneidet.

Den Code im visu.js habe ich so angepasst, dass stringify und eval genutzt werden, um die Daten von JSON object in String und zurück zu wandeln.

Nun könnte man sich mit der Interpretation in fhem beschäftigen. Welchen Grundansatz hältst Du für sinnvoll?
Im uzsu-Converter einen notify triggern, der in fhem die nötigen at Befehle erstellt? Wäre einfach, oder?

Was meinst Du?

Alle Änderungen sind im git (fhem und SV).

Hi,

ja, bin leider noch nicht dazu gekommen da tiefer einzusteigen - ich schaff ja nicht mal mein sv weiter einzurichten 

Grundsätzlich würde ich vorschlagen die Übernahmen in fhem nochmal ohne Anpassung vom widget zu versuchen (also ich, musst Du nix machen).

Danach kommt aber, so wie Du sagst, der Punkt wo es spannend wird:

wenn wir da mit notify und at rangehen wird das mMn recht schnell komplex. Die Daten müssen ja von JSON in eine (variable) Struktur gebracht werden. Logisch kann man das auch mit notify (plus viel perl wegen Zeiten extrahieren) und at lösen.

Für die uzsu halte ich es für sinnvoll ein fhem device zu erstellen. Das magst Du jetzt nicht gerne hören weil Du das möglichst schnell willst - gelle ?  Ich glaube auch das fhem sowieso noch kein solches device kennt - der weekday timer den ich mir mal dafür angeschaut hatte arbeitet scheinbar direkt mit einem Heizungsmodul zusammen, insofern besteht da vmtl sowieso ein need. Mit Andre hatte ich schon mal gesprochen, der würde generell das widget für fhemweb bauen wollen (ich finde Sonderlocken nicht so doll).

Soweit ich das sehe müssten wir, mit dem update von gestern, eigentlich wieder stabil genug unterwegs sein. Ich will mir sowieso einen fhem-sv-Wecker device bauen (weil ich sv auch auf einem Radiowecker betreibe). Da könnte ich das in einem Rutsch mit machen. Wenn nichts dazwischen kommt 1,2 tage.

Wäre ok ?

vg
jörg

[herrmannj]

Meine auch. Und ich denke, ich habe von allen vorhandenen Firmwareversionen mindestens ein Gerät

Ich denk ja auch das es an mir liegt ... nur:

Code Auswählen Erweitern

model HM-CC-VD
D-firmware 2.0
das einzige battery reading das ich finde ist "ok"

Code Auswählen Erweitern

battery ok

Code Auswählen Erweitern


model HM-CC-TC
firmware 2.1

...

Code Auswählen Erweitern

battery ok

gepaird sind die, fhem von kurz vor Weihnachten. ... Wie sieht das reading denn bei Euch aus  ?

danke und Grüße
jörg

edith, einige vd sind 1.9 - da siehts aber genauso aus.

[herrmannj]

@all:

beseitigt das aktuelle update das "disconnect" zufriedenstellend ?

vg
jörg

[dancatt]

Hallo zusammen,
ich habe unter http://www.fhemwiki.de/wiki/Installation_Fronthem einen ersten Wurf der Installationsanleitung.
Habe diesen auch in http://www.fhemwiki.de/wiki/Fronthem verlinkt.
Bei Gelegenheit könnt ihr ja mal drüberschauen, ändern oder euch hier melden.
Vielen Dank.

[bgewehr]

...

Code Auswählen Erweitern

battery ok
...

Jedes HM-TC und HM-CC besteht doch aus mehreren fhem-devices. Z. B. das XXX.clima. Darin findet man den Link zum XXX-device (der "Mutter").
Darin ist bei mir in beiden Fällen

Code Auswählen Erweitern


battery ok 2014-12-24 00:05:25
batteryLevel 3.1 2015-01-11 16:49:01


Ich habe Firmware 1.3!

[bgewehr]

Grundsätzlich würde ich vorschlagen die Übernahmen in fhem nochmal ohne Anpassung vom widget zu versuchen (also ich, musst Du nix machen).

Danach kommt aber, so wie Du sagst, der Punkt wo es spannend wird:

wenn wir da mit notify und at rangehen wird das mMn recht schnell komplex. Die Daten müssen ja von JSON in eine (variable) Struktur gebracht werden. Logisch kann man das auch mit notify (plus viel perl wegen Zeiten extrahieren) und at lösen.

Für die uzsu halte ich es für sinnvoll ein fhem device zu erstellen. Das magst Du jetzt nicht gerne hören weil Du das möglichst schnell willst - gelle ?  Ich glaube auch das fhem sowieso noch kein solches device kennt - der weekday timer den ich mir mal dafür angeschaut hatte arbeitet scheinbar direkt mit einem Heizungsmodul zusammen, insofern besteht da vmtl sowieso ein need. Mit Andre hatte ich schon mal gesprochen, der würde generell das widget für fhemweb bauen wollen (ich finde Sonderlocken nicht so doll).

Soweit ich das sehe müssten wir, mit dem update von gestern, eigentlich wieder stabil genug unterwegs sein. Ich will mir sowieso einen fhem-sv-Wecker device bauen (weil ich sv auch auf einem Radiowecker betreibe). Da könnte ich das in einem Rutsch mit machen. Wenn nichts dazwischen kommt 1,2 tage.

Hier ist der Python-Code, mit dem das JSON in smarthome.py ausgewertet und interpretiert wird:
https://github.com/mknx/smarthome/blob/develop/plugins/uzsu/__init__.py

Vielleicht hilft's ja!

[herrmannj]

Jedes HM-TC und HM-CC besteht doch aus mehreren fhem-devices. Z. B. das XXX.clima. Darin findet man den Link zum XXX-device (der "Mutter").
Darin ist bei mir in beiden Fällen

Code Auswählen Erweitern


battery ok 2014-12-24 00:05:25
batteryLevel 3.1 2015-01-11 16:49:01


Ich habe Firmware 1.3!

danke. Bin beim TC auf der Mutter - ( vd haben bei mir keine) - da ist nur battery ok. Dann ich aber insofern schlauer das mir ein reading fehlt, entweder weil die fw anders ist oder weil ich was falsch mach, irgendein register nicht gelesen habe oder so was in der Art. Ist zum Glück nicht Kriegsentscheidend - ich schieb das mal auf  Danke, jörg

[herrmannj]

Hier ist der Python-Code, mit dem das JSON in smarthome.py ausgewertet und interpretiert wird:
https://github.com/mknx/smarthome/blob/develop/plugins/uzsu/__init__.py

Vielleicht hilft's ja!

Ja super, Danke. Das interpretieren ist mMn recht entspannt. Für mich ist eher die Frage wie man das vernünftig in fhem integriert, und zwar in zwei Punkten:

zum ersten kannst Du bei der uzsu doch beliebig viele Schaltgruppen erstellen, zumindest habe ich das so verstanden. Das läßt sich in fhem schlecht in readings abbilden (weil variable Anzahl). Da könnte ich mir vorstellen das man die einzelnen Gruppen per "get" abfragen kann und nur ein reading für das jeweils folgende event erstellt.

punkt 2 betrifft die konkrete Aktionen die ausgelöst werden sollen. Also nehmen wir mal an Du erstellst 3 Gruppen, jeweils für eine andere Jalousie. Die fhem Seite muss ja jetzt (wenn eingestellte Zeit erreicht ist) eine konkrete Aktion auslösen (Jalousie morgens hoch, Abends runter)

     Variante a: an dem fhem uzsu part wird konkret eingestellt was passieren soll (set x on)
     Variante b: das fhem device sendet ein event, und man erstellt ein notify was darauf reagiert.

a ist wieder doof umzusetzen (wegen variabler Anzahl von möglichen Gruppen).

Daher würde ich zu b (event von der uzsu, notify macht) tendieren. So ein Event könnte dann so aussehen: "uzsu <group1> on"

Meinungen, Ideen, Anregungen ?

vg
jörg 

[pole23]

danke. Bin beim TC auf der Mutter - ( vd haben bei mir keine) - da ist nur battery ok. Dann ich aber insofern schlauer das mir ein reading fehlt, entweder weil die fw anders ist oder weil ich was falsch mach, irgendein register nicht gelesen habe oder so was in der Art. Ist zum Glück nicht Kriegsentscheidend - ich schieb das mal auf  Danke, jörg

Hallo,
kann es sein, das es sich hierbei um zwei verschiedene Geräte handelt? Lauf Commandref gibt es bei einem HM-CC-VD das Reading "battery:[critical|low|ok]" und HM-CC-TC nur das Reading "battery:[low|ok]".
Das Reading "batteryLevel $bat V" tauch nur bei den neueren HM-CC-RT-DN auf.
Daher habe ich mir für die Batterieanzeige folgendes UserReading erstellt".

Code Auswählen Erweitern

battRel {battRel(ReadingsVal('bz_Stellantrieb','battery',''))}

Und folgendes für die 99_MyUtils.pm

Code Auswählen Erweitern


sub battRel($) {
my ($state) = @_;
  if ($state eq "ok") {
  my $ret=100;
    return $ret
  }
  if ($state eq "low") {
  my $ret=20;
    return $ret
  }
  if ($state eq "critical") {
  my $ret=0;
    return $ret
  }
  return 0;
}

[justme1968]

hallo zusammen,

jörg hatte mich gefragt ob ich interesse habe für die zeitschaltuhr auch eine darstellung/widget beizusteuern mit der das device im normalem fhemweb frontend darstellbar und bedienbar ist.

ich habe die posts zur uzsu gerade erst kurz überflogen. dabei sind natürlich direkt ein paar fragen und bemerkungen aufgetaucht:

- der WeekdayTimer ist nicht (mehr) heizungs spezifisch. das urpsüngliche modul war zwar HeatingControl aber das konzept ist eigentlich allgemeiner und deshalb sollte das device umbenannt werden. da das aber probleme bei bestehenden anwendern verursacht hätte wurde WeekdayTimer zusätzlich zu HeatingControl eingecheckt und beide verwenden intern zum grossen teil den gleichen code.

- vermutlich ist es normalerweise sinnvoll mehr als solches device für dedizierte aufgaben zu haben und nicht nur eine einzige schaltuhr für alles mögliche. seht ihr das auch so?

- die uzsu 'nur' für die schaltzeiten zu haben und das eigentliche schalten über notifys zu machen hat den vorteil das man z.b. das gruppieren von devices auch durch bestehende fhem konstrukten wie structure oder LightScene machen kann.

- mir ist noch nicht ganz klar welchen funktionsumfang die uzsu genau haben soll. bzw. aus welcher richtung das desgin genau kommen soll. d.h. ob es primär um das gui geht das (nur) bestimmte dinge ermöglichen soll und das backend device dem folgt, oder ob es um funktionalität im backend geht (so universell wie möglich) die dann (so gut es geht) mit einem passenden frontend versehen werden sollen.

- diese frage stellt sich z.b. besonders wenn es darum geht wie die existierenden sunset/sunrise funktionen eingebunden werden sollen. mit perl aufrufen ist es unschlagbar flexibel aber im frontend nicht vernünftig darstellbar.

- es wäre schön wenn es eine vorausicht der nächsten schaltzeiten über mindestens eine woche gibt und hier auch die sich ändernden sonnenauf- und -untergangszeiten widerspiegeln.

ich hoffe als seiteneinsteiger ist es ok erst mal zu fragen...

gruss
  andre

[Jojo11]

@all:

beseitigt das aktuelle update das "disconnect" zufriedenstellend ?

vg
jörg

Hallo,

wenn ich jetzt smartVISU aufrufe, ist mein device connected, das rote Dreieck ist weg, aber keine Werte werden angezeigt. Der Editor ist leer. Vermutlich geht es wieder, wenn ich FHEM neustarte. Habe heute aktualisiert.

schöne Grüße
Jo

[herrmannj]

jörg hatte mich gefragt ob ich interesse habe für die zeitschaltuhr auch eine darstellung/widget beizusteuern mit der das device im normalem fhemweb frontend darstellbar und bedienbar ist.

Danke fürs rein schauen, trotz dem fhemweb.js Umbau Streß. 

- der WeekdayTimer ist nicht (mehr) heizungs spezifisch. das urpsüngliche modul war zwar HeatingControl aber das konzept ist eigentlich allgemeiner und deshalb sollte das device umbenannt werden. da das aber probleme bei bestehenden anwendern verursacht hätte wurde WeekdayTimer zusätzlich zu HeatingControl eingecheckt und beide verwenden intern zum grossen teil den gleichen code.

verstehe, ich hab die includes gesehen und das falsch interpretiert. Da schau ich nochmal um Doppelentwicklung zu vermeiden.

- vermutlich ist es normalerweise sinnvoll mehr als solches device für dedizierte aufgaben zu haben und nicht nur eine einzige schaltuhr für alles mögliche. seht ihr das auch so?

yes!

- die uzsu 'nur' für die schaltzeiten zu haben und das eigentliche schalten über notifys zu machen hat den vorteil das man z.b. das gruppieren von devices auch durch bestehende fhem konstrukten wie structure oder LightScene machen kann.

sehe ich auch so.

- mir ist noch nicht ganz klar welchen funktionsumfang die uzsu genau haben soll. bzw. aus welcher richtung das desgin genau kommen soll. d.h. ob es primär um das gui geht das (nur) bestimmte dinge ermöglichen soll und das backend device dem folgt, oder ob es um funktionalität im backend geht (so universell wie möglich) die dann (so gut es geht) mit einem passenden frontend versehen werden sollen.

Das widgets gibt es für sv, die Funktionalität (schalten) soll das fhem device erbringen. Wenn am design (sv) was geändert werden muss das geht das. Ich bin gerade beim installieren, lernen, verstehen - ich stelle nachher mal einen screenshot rein wenn Bernd nicht sogar schneller ist. In fhem muss die Bedienung (GUI) "erfunden" werden.

- diese frage stellt sich z.b. besonders wenn es darum geht wie die existierenden sunset/sunrise funktionen eingebunden werden sollen. mit perl aufrufen ist es unschlagbar flexibel aber im frontend nicht vernünftig darstellbar.

Da sehe ich kein problem (und ja, geiles feature). Die zeiten können ja in fhem angepasst werden, muss man sich jetzt fragen wie das in der GUI und vom workflow laufen soll. Ich nehme so eine Zeitschaltuhr ja unter Umständen auch für Aufgaben die völlig unabhängig von ss/sr sind. Ladenöffnungszeiten zb.

- es wäre schön wenn es eine vorausicht der nächsten schaltzeiten über mindestens eine woche gibt und hier auch die sich ändernden sonnenauf- und -untergangszeiten widerspiegeln.

screenshot kommt, dann siehst Du das.

ich hoffe als seiteneinsteiger ist es ok erst mal zu fragen...

logitsch!  je mehr desto besser.

danke und Grüße
Jörg

[herrmannj]

Hallo,

wenn ich jetzt smartVISU aufrufe, ist mein device connected, das rote Dreieck ist weg, aber keine Werte werden angezeigt. Der Editor ist leer. Vermutlich geht es wieder, wenn ich FHEM neustarte. Habe heute aktualisiert.

schöne Grüße
Jo

das mit gad weg hattest Du schon mal, richtig ? Nach dem update Neustart gemacht ? Die GADs dürfen im Betrieb nicht weg sein. Was bei mir noch offen ist: wenn man von der gleichen ip aus gleichzeitig, mehrfach zugreift (browser, mehrere tabs) das wird (noch) nicht abgefangen, Probleme sind da zu erwarten. Rename (noch) don't do. Erst Mutter dann device definieren. Sonst: Hast Du einen Verdacht ?

vg
jörg

[Jojo11]

pffff, ich habe keinen Plan. Kommt mir so vor, als würde die Verbindung einschlafen. Das mit den tabs kann sein, das mache ich regelmäßig.
Gerade sudo restart ohne Absturz überlebt -> läuft wieder.
Wenn ich ein Muster erkenne, gebe ich Bescheid 

schöne Grüße
Jo

[herrmannj]

ja cool. Aber ich hab auch Baustellen offen (siehe tabs). Pass nur bitte auf, wenn Du bei leerer GAD list speicherst -- isse wech

Kommt mir so vor, als würde die Verbindung einschlafen.

spricht für mehrer Tabs vs eine ip.

Gerade sudo restart ohne Absturz überlebt -> läuft wieder.

"sudo ..." oder "shutdown ..."? shutdown sollte ok sein. Bei sudo bin ich raus 

vg
jörg