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

[HCS]

Comfortchart funktioniert auch jetzt und ohne irgendeine Anpassung schon. Der benötigt ja nur 2 AKTUELLE Werte für Temperatur und Humidity. Das muss nichts angepasst werden.

Praktisch. Arbeit gespart. 

[Carsten]

Temprose müsste doch auch schon funktionieren, oder?
Will ja auch nur Ist und Soll in Arrayform

[marvin78]

Probiere es aus Aber ich denke, du hast recht. Temprose sollte gehen.

[Carsten]

Probiere es aus Aber ich denk, du hast recht. Temprose sollte gehen.

Ich habe aktuell nur zwei Thermostate im Einsatz. Da ist das Ergebnis ein wenig seltsam. 
Habe versucht, die Thermostaten jeweils doppelt einzubinden, aber dann stimmt für die zweiten der Wert nicht. Glaube aber nicht, dass das an FHEM bzw. Fronthem liegt. Prinzipiell zeigt er es aber an.

[HCS]

Ich habe aktuell nur zwei Thermostate im Einsatz. Da ist das Ergebnis ein wenig seltsam. 
Habe versucht, die Thermostaten jeweils doppelt einzubinden, aber dann stimmt für die zweiten der Wert nicht. Glaube aber nicht, dass das an FHEM bzw. Fronthem liegt. Prinzipiell zeigt er es aber an.

Praktisch. Noch mehr Arbeit gespart. 
Dann sind es nur noch zwei Widgets, bei denen wir auf eigene zurückgreifen müssten. Wobei der plot.rtr auch nichts dramatisch Anderes als der period ist.
Und wenn der period ausreichend konfigureirbar wird und optional zoom vernünftig kann, dann braucht man vermutlich auch nicht viel mehr.

[marvin78]

@hermannj: Wenn ich in Zeile 200 der  fhconverter.pm

Code Auswählen Erweitern

$event = $1;

durch

Code Auswählen Erweitern

$event =~ /\D*([+-]{0,1}\d+[.]{0,1}\d*).*?/;

und in Zeile 212

Code Auswählen Erweitern

$gadval = $1

durch

Code Auswählen Erweitern

$gadval =~ /\D*([+-]{0,1}\d+[.]{0,1}\d*).*?/;

ersetze, funktionieren die Vorzeichen für NumDirect wieder. Hier scheint das RegEx also nicht korrekt in $1 zu stehen.

[ftobi]

Hallo,

hab ein Homematic Schalter, der nicht immer zuverlässig antwortet. Der geht dann auf state MISSING ACK.
Der OnOff-Converter macht da wohl auch fälschlicherweise ein On draus.

Grüße
Tobi

[marvin78]

@ftobi: da solltest du aber zuerst einmal der Ursache für diese Unzuverlässigkeit auf den Grund gehen. Oder eben einen anderen Converter verwenden. Der Sinn des OnOff Convertes ist ja, dass er nur mit OnOff umgehen kann (bzw. die Umsetzung auf 1 und 0).

[HCS]

@ftobi: da solltest du aber zuerst einmal der Ursache für diese Unzuverlässigkeit auf den Grund gehen. Oder eben einen anderen Converter verwenden. Der Sinn des OnOff Convertes ist ja, dass er nur mit OnOff umgehen kann (bzw. die Umsetzung auf 1 und 0).

Da wäre dann ein nullable bool cool 
Eigentlich bräuchte man noch einen Tri-State Converter + Widget

[marvin78]

Im Grunde lässt sich das mit dem Direct-Converter doch machen. Ein Widget, dass bei mir die Alarmanlage schaltet (on,set_on,set_off,off - Kombination aus dem Keypad und einem basic.switch), war darauf sehr einfach und schnell realisiert.

[ftobi]

@ftobi: da solltest du aber zuerst einmal der Ursache für diese Unzuverlässigkeit auf den Grund gehen. Oder eben einen anderen Converter verwenden. Der Sinn des OnOff Convertes ist ja, dass er nur mit OnOff umgehen kann (bzw. die Umsetzung auf 1 und 0).

sry, hab ich nicht hingeschrieben. Das ist schon klar, dass für Produktivbetrieb die Unzuverlässigkeit weg muss.
Aber für frontHEM dacht ich, ich geb das Verhalten mal hier rein. Ein altes FS20-Relikt hatte auch An/Aus als State und da hatte der OnOff Converter nicht drauf reagiert, bis ich das Device auf On / Off umgestellt habe. Deshalb dachte ich, der Sinn des OnOff Converters ist, dass er eben nur On oder Off und sonst nichts weitergibt.

Aber wenn das Verhalten as desired ist, dann passt ja alles

Grüße
Tobi

[herrmannj]

Hi ftobi,

& Danke. Aber ja: ist bei Design - in der Hauptsache ist das so für die milight und hue weil die "off" und "on 100" und so etwas machen. Ich habe aber auch schon überlegt den rein auf "on" "Off" umzustellen und gleichzeitig einen regex-converter anzubieten. Den hatte Bernd mal vorgeschlagen da war mir das zu kompliziert (für den Benutzer, nicht vom programmieren). Mittlerweile denke schon das es Anwendungen dafür gibt.

Für den Schalter: ein tri-state widget an sich gibt es ja nicht aber Du könntest Dir ein basic.icon mit einem Ausrufezeichen daneben setzen und das auf "missing_ack" triggern. Dann wäre der Schalter mit "on" "off" normal belegt und im Falle des Fehler würde das Ausrufezeichen zusätzlich erscheinen. Nur so als Idee, könnte man auch mit notify.warn als dialog machen.

@marvin:
ich bin unterwegs und kann bis zum we nur umständlich testen. Mit der Regex wollte ich erreichen das auch "T: 20" als "20" erkannt wird. Wenn das so funktioniert würde ich das gern übernehmen, sonst muss ich nochmal schauen.

vg
jörg

[marvin78]

@marvin:
ich bin unterwegs und kann bis zum we nur umständlich testen. Mit der Regex wollte ich erreichen das auch "T: 20" als "20" erkannt wird. Wenn das so funktioniert würde ich das gern übernehmen, sonst muss ich nochmal schauen.

Dein Regex ist ja nicht falsch. Ich habe ihn ja so übernommen nur steht er offenbar nicht in $1. An der Stelle ist mir Perl aber auch (noch) zu fremd.

[HCS]

ich bin unterwegs und kann bis zum we nur umständlich testen.

So geht es mir auch gerade. Aber wir haben ja auch keinen Stress 
Am WE schauen wir dann mal weiter ...

[marvin78]

Wenn man als reading im gad etwas anderes als state verwendet (bspw. bState), als cmd set jedoch state, dann wird "state" auch mit dem Befehl beim Schalten übergeben. Fhem registriert in dem Fall also sowas wie

Code Auswählen Erweitern

set DEVICE state on

und sagt im Log dann sowas wie

Code Auswählen Erweitern

set DEVICE state on : Unknown argument state, choose one of ...

Ist das so gewollt? Ich meine, das hätte auch schon anders (besser) funktioniert. Zudem wäre es eigentlich ungemein praktisch, wenn man reading und cmd set unabhängig voneinander auch bei state verwenden könnte.

Weitere Dinge, die mir aufgefallen sind:

Treiber: Sind mit der Zeit viele Seiten im Dom, wird, bei angeschaltetem Cache und Laden der Seiten per AJAX, das aktualisieren der Gads immer träger. Das liegt vermutlich daran, dass vom Treiber zwar nur die gads aktualsiert werden, die sichtbar sind, aber per each das ganze DOM durchsucht wird. Das wird nach spätestens ab 5 Seiten unerträglich und führt sogar irgendwann dazu, dass gads gar nicht mehr aktualsiert werden, weil der Browser sie "verschluckt".

Am performantesten ist SmartVisu eigentlich ohne jeden Cache und vor allem mit data-ajax="false".

Ist es möglich, dass der Treiber bei Wiederverbindung mit FHEM auch direkt einen refresh der Widgets durchführt? SmartVisu bekommt sonst zwischenzeitliche Änderungen (von Devices die nur selten ihren Status ändern) nicht mit. Ich habe mir als Workaround die refresh Funktion folgendermaßen in die root.html geschrieben:

Code Auswählen Erweitern

var myVar = setInterval(function(){  io.refreshWidgets();io.monitor();console.log("refresh")}, 100000);

Das bringt aber leider noch nichts, falls man den Cache an hat und zu einer Seite zurück wechselt, die schon im Cache ist. SmartVisu bekommt dann zwar neue Änderungen mit aber nicht alle, die zwischen Dis- und ReConnect stattgefunden haben. Auch hier muss man ohne Cache und am besten auch wieder ohne data-ajax=true arbeiten, um ein vernünftiges Ergebnis zu erzielen.