98_cloneDummy.pm [war: Erweiterungsvorschlag für 98_dummy.pm]

[Groby]

Hallo Joachim,

kannst Du Events für state nicht umgehen, wenn Du setstate verwendest?

Warum? Ich denke da an cyclic messages von Heizkörpern, Wetterstationen u.ä. Was soll mir da ein T-reading sagen?

Code Auswählen Erweitern


Events
CUL_HM WetterStation T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188
CUL_HM HK_Kueche T: 22.1 desired: 22.0 valve: 100

Readings
"T"    "7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"
"T"    "22.1 desired: 22.0 valve: 100"


Wie soll man state wiederherzustellen, wenn man kein stateFormat anwenden kann?

Code Auswählen Erweitern


stateFormat T: T usw -> funktioniert so nicht...



Bei den technischen Feinheiten kann ich nicht mitreden, das überlasse ich den Profis. Ich sehe das aus der Sicht der Anwenders und mir persönlich würden die updates der "states" definitiv fehlen. Ausserdem glaube ich, dass man nicht jeden Event sauber "splitten" kann.

Anbei ein notify, dass dummies auf fhem2 automatisch anlegt:

Code Auswählen Erweitern


define Watch_cloneDevice notify .* {if((ReadingsVal("F2".$NAME,"state","?")eq"?")&&(substr($NAME,0,2)ne"F2")&&($NAME ne"global")) {fhem('define F2'.$NAME.' dummy')}};;



MfGroby

[Joachim]

Moin Groby,
Seit heute mogen sollte das Modul im regulären Update sein.
Dabei ist die standart Einstellung, dass der state von initialized nach active wechselt.
Ein stateFormat funktioniert bei mir einwandfrei, wenn Du dabei Probleme hast, dann brauche ich mehr Informationen.
- aussagekräftigen Auszug aus dem Eventmonitor
- komplette definition des Moduls mit den gesetzten attr

Gruß Joachim

[Olaf A]

Hallo Ihr,

habe ein Updatecheck durchgeführt, es ist drin. 

Danke Jo und betateilchen

Gruß
Olaf

[Groby]

Joachim,

das update habe ich mir natürlich direkt heute morgen gezogen.

Solange "state" immer den kompletten "state" des Original devices enthält, gibt es keine Probleme. Ich kann dir Anhand der Wetterstation Events einmal versuchen zu erklären was ich meine.

Event:

Code Auswählen Erweitern

CUL_HM WetterStation T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188

Jetzt:

Code Auswählen Erweitern


"state" "T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"
"T" 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188


Kein Problem, da man immer noch den Original "state" wegschreiben kann. Sofern aber "state" nicht mehr kopiert wird, wäre das Modul für mich unbrauchbar, da ich immer den kompletten "state" wegschreiben will um Regenmenge usw. zu berechnen. Ansonsten müsste ich temperature, humidity, windSpeed usw. jeweils einzeln aus der Logdatei auslesen.

D.h. wenn Du das Modul weiterentwickelst und den "state" splittest oder einzelne Events erwartest wäre es für mich unbrauchbar.

Readings splitting ohne "state" updates (im Modul oder einzelne Events):

Code Auswählen Erweitern


"T" "7"
"H" "85"
"W" "3.6"
"R" "159.005"
"IR" "0"
"WD" "10"
"WDR" "67.5"
"S" "188"


Aus diesen Werten würde ich den original "state" nie wieder zusammen bekommen da "stateFomat F2WetterStation T: T H: H W: W R: R IR: IR WD: WD WDR: WDR S: S" nicht funktioniert. Deswegen ist mir das portieren des original "state" wichtig, auch wenn es ggf. einen zusätzlichen z. Zt. Event gibt.

Die Idee die ich dazu hatte doppelte Events zu filtern war folgende. Das cloneDevice bekommt per Default nur "state" kopiert, es sei den man legt nachträglich ein attr an, welches die readings listet die Du "splitten" sollst, um "doppelte Events zu vermeiden...

also "Default" oder "attr F2WetterStation state" nur:

Code Auswählen Erweitern


"state" "T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"


wenn "attr F2WetterStattion T,H,W" ->dann

Code Auswählen Erweitern


"T" "7"
"H" "85"
"W" "3.6"


oder "attr F2WetterStattion state,T,H,W" ->dann

Code Auswählen Erweitern


"state" "T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188"
"T" "7"
"H" "85"
"W" "3.6"


Wie gesagt so wie das Modul jetzt läuft ist es ok, aber wenn es um Filtern von doppelten Events geht, wäre o.g. Beispiel ein möglicher Lösungsansatz...

MfGroby

[Joachim]

Moin Groby,
Ich muss mich jetzt ersteinmal selber mit meinem Modul vertraut machen, ein Testsysten bauen, und etwas mit dem Modul herumspielen.
Ich glaube, dass ich verstanden habe, was Du willst.
Ich versuche mal, das ganze zusammenzufassen:

Ich verzweifele gerade daran, einen "notify" zu erstellen, der alle events in ein "F2dummy" überführt. So eine Art autocreate.

Wenn ich das richtig verstehe, möchtest Du, dass Devices aus FHEM2FHEM automatisch angelegt werden, wenn gewünscht.
Könnte irgenwann mal kommen, steht aber ganz unten auf meiner todo-Liste.

Als default nach dem Erstellen von F2dummy denke ich, dass das updaten von "state" am meisten Sinn macht, da man nicht weiss ob es sich um ein Multireading handelt (mehere ":", spaces, "=" usw.) oder nicht.

Wird es so definitv nicht geben, da in den Events nicht zu erkennen ist, welcher der Events der STATE ist. Aber ich könnte mir vorstellen, dass ich in der Moduldefinition eine Möglichkeit schaffe, zu bestimmen, welches reading in den STATE wandern soll. Bis dahin kann man sich mit stateFormat den STATE so einstellen, wie gewünscht, also z.B. so

Code Auswählen Erweitern

define Bad cloneDummy FS_Bad
attr Bad room Bad
attr Bad stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f",ReadingsVal("Bad","Temperatur",0), ReadingsVal("Bad","Feuchte",0), ReadingsVal("Bad","dewpoint",0), ReadingsVal("Bad","absFeuchte",0))}

Von dort sollte es dem User möglich sein per attr zu definieren welche readings geklont werden sollen:

Wird so nicht kommen, da das Modul dazu da ist, Devices zu Klonen. Werte, die nicht gewünscht sind, kann man im Originaldevice blocken. Vielleicht baue ich irgendwann einmal eine exclude Funktion ein. Steht aber auch recht weit unten auf der todo-Liste.

kannst Du Events für state nicht umgehen, wenn Du setstate verwendest?

Das ist zu Hälfte ein Problem von FHEM und zur anderen Hälfte ein Problen Deine Definition im Originaldevice.
FHEM sendet leider in den Events die Information nicht mit, welches Reading der STATE ist und

CUL_HM WetterStation T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188

müsste eigentlich als

Code Auswählen Erweitern

CUL_HM WetterStation STATE: T: 7 H: 85 W: 3.6 R: 159.005 IR: 0 WD: 10 WDR: 67.5 S: 188
geliefert werden, da dies so nicht der Fall ist, wird das T als readingsname erkannt, alles was dahinter ist, als reading. Das geht natürlich schief. Hier muss eine Lösung gefunden werden, gib mir etwas Zeit.

Wie soll man state wiederherzustellen, wenn man kein stateFormat anwenden kann?

stateFormat geht, s.o.

Bei den technischen Feinheiten kann ich nicht mitreden, das überlasse ich den Profis. Ich sehe das aus der Sicht der Anwenders und mir persönlich würden die updates der "states" definitiv fehlen. Ausserdem glaube ich, dass man nicht jeden Event sauber "splitten" kann.

Ich bin auch Anwender, und habe keine Ahnung von Perl. Allerdings kann ich mit Google umgehen, und durch lesen, testen und Hilfe habe ich dieses Modul für mich geschrieben, und der Allgemeinheit zur Verfügung gestellt.

Anbei ein notify, dass dummies auf fhem2 automatisch anlegt:

Sehe ich mir an, und versuche es zu Verstehen, vielleicht kann man davon was im Modul übernehmen.

Zu Deinem letzte Post mal folgender Kommentar:
Ich hatte Dich gebeten,

Moin Groby,
Seit heute mogen sollte das Modul im regulären Update sein.
Dabei ist die standart Einstellung, dass der state von initialized nach active wechselt.
Ein stateFormat funktioniert bei mir einwandfrei, wenn Du dabei Probleme hast, dann brauche ich mehr Informationen.
- aussagekräftigen Auszug aus dem Eventmonitor
- komplette definition des Moduls mit den gesetzten attr

Gruß Joachim

Deine Antwort darauf enthielt weder

- aussagekräftigen Auszug aus dem Eventmonitor

noch

- komplette definition des Moduls mit den gesetzten attr

sondern ein Text, mit dem ich nicht wirklich etwas anfangen kann, und ich habe ihn mittlerweile diverse male gelesen.
Liefere bitte die gewünschten Informationen um die man Dich bittet, und bevor Du eine Antwort sendest, denke daran, dass der gegenüber im Normalfall kein Gedankenleser ist. Bitte versuche das ganze so zu strukturieren, das auch jemand, der nicht in Deinen Gedanken sitzt, das ganze versteht. Für Halbsätze ist Piet Klocke zuständig.

Gruß Joachim

[betateilchen]

1. das Ändern von state ist in aller Regel kein wirklicher Event und Änderungen an state werden von fhem komplett anders gehandhabt als alle anderen Readings. Deshalb macht ein Triggern auf state keinen Sinn. Wie schon mehrfach geschrieben wurde, kann jederzeit stateFormat verwendet werden, um im clone einen STATE in der gewünschten Form zu erzeugen. Bitte nicht immer state und STATE verwechseln Das Reading state gehört immer zum definierten Device selbst und das ist hier der Clone und nicht das Originaldevice irgendwo anders.

2. das automatische Anlegen eines cloneDummys wäre eine Aufgabe des autocreate-Moduls, das müsste dann Rudi übernehmen. Das müsste dann am sinnvollsten über ein Attribut von fhem2fhem und/oder autocreate gesteuert werden.

[eldrik]

Hallo Joachim,

klasse Umsetzung, genau dieses Modul brauche ich, um meine 1Wire Geräte aus Performancegründen nicht mehr über OWServer, an meiner Hauptinstanz betreiben zu müssen.

Das absetzen von Befehlen von der Hauptinstanz an die Slaveinstanzen wäre natürlich Klasse, scheint aber derzeit out of scope zu sein

Funktioniert longpoll eigentlich für den State, welcher via stateformat generiert wird? Bei mir funktioniert es derzeit leider nicht.

Greetz
Eldrik

[Groby]

Joachim,

alles was Du an Informationen brauchst, findest Du bereits in der letzten Antwort:

Die Wetterstation sendet cyclic Messages (inform on):

Code Auswählen Erweitern


CUL_HM WetterStation T: 7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42


ein cloneDummy device erzeugt:

Code Auswählen Erweitern


"T" "7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"

stateFormat T: T liefert dann:

Code Auswählen Erweitern


"7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 427.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"


ein dummy device erzeugt:

Code Auswählen Erweitern


"T" "7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"
"state" "T: 7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"


stateFormat wird hier nicht benötigt:

Code Auswählen Erweitern


"state" "T: 7.2 H: 73 W: 15.7 R: 163.725 IR: 0 WD: 65 WDR: 67.5 S: 95 B: 42"


Gleiches Problem stellt sich bei Heizkörpern und Thermometern mit cyclic Messages:

Event:

Code Auswählen Erweitern


"CUL_HM HK_Kueche T: 23.5 desired: 22.0 valve: 70"

wird portiert nach

Code Auswählen Erweitern


"T" "23.5 desired: 22.0 valve: 70"


Event:

Code Auswählen Erweitern


CUL_HM HygroMeter T: 23.5 H: 65

wird portiert nach

Code Auswählen Erweitern


"T" "23.5 desired: 22.0 valve: 70"


Ich erwarte hier keine Lösung von Dir, aber mit einem einzelnen "T" reading kann ich persönlich nichts anfangen.

Groby

[Groby]

@betateilchen

es mag sein, dass es programmiertechnisch einen Unterschied von state & STATE gibt.

Im WEB frontend liefern aber set und setstate das gleiche Ergebnis für mich. set mit Event & setstate ohne...

MfGroby

[betateilchen]

Ich glaube, Ihr redet grade mächtig aneinander vorbei. Das stateFormat wird nicht im sourceDevice gebraucht, sondern im Clone.

Tipp: Leg Dir mal im Sourcedevice ein userreading an, das genau so aussieht wie state. Dann sollte dieses userreading automatisch auch im Clone auftauchen.

[betateilchen]

es mag sein, dass es programmiertechnisch einen Unterschied von state & STATE gibt.

nein, nicht programmtechnisch, sondern optisch.

Im WEB frontend liefern aber set und setstate das gleiche Ergebnis für mich. set mit Event & setstate ohne...

Das mag für Dich so aussehen es ist aber definitiv nur eine "optische Täuschung"

[justme1968]

set und setreading schreiben beides state. STATE kannst du garnicht direkt beschreiben. nur über stateFormat setzen wenn das modul das unterstützt.

den unterschied zwischen state und STATE siehst du bei ReadingsVal und Value. ersteres liest state letzteres STATE.

gruss
  andre

[Groby]

@betateilchen

der "state" der WetterStation ist default ohne "stateFormat" und sollte auch genauso von cloneDummy übernommen werden.

Warum sollte ich als "User" im SourceDevice noch diverse "userreadings" zum "clonen" anlegen???
Oder neue Events generieren per "event-on-change-reading"

Das macht m.E. überhaupt keinen Sinn. Da kann ich besser wie bisher mit FHEM2FHEM & notifies arbeiten...

MfGroby

[justme1968]

state hat leider eine sonderstellung unter den readings und es ist technisch nicht möglich es über notifys und events eindeutig zu erkennen und zu parsen. rudi weiß das hat aber keine Idee wie man das rückwärtskompatibel und ohne overhead ändern kann.

die lösung für dein problem ist wirklich stateFormat für den dummy zu setzen. ich denke das ist immer noch einfacher und klarer als alles selber über events und notifys zu regeln.

gruss
  andre

[Joachim]

Moin Groby,
wie soll ich es Dir Erklären, wenn Du nicht das machst, was ich schreibe.
Zum dritten mal:
- aussagekräftigen Auszug aus dem Eventmonitor
der sieht z.B. so aus:

Code Auswählen Erweitern


2014-03-21 11:37:20.445 cloneDevice OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:20.445 OWTHERM OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:20.458 cloneDevice OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:20.458 OWTHERM OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:20.470 cloneDevice OWX_28_6119BA030000 Temperatur: 15.88
2014-03-21 11:37:20.470 OWTHERM OWX_28_6119BA030000 Temperatur: 15.88
2014-03-21 11:37:48.003 cloneDevice sysmon eth0_diff: RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
2014-03-21 11:37:48.003 SYSMON sysmon eth0_diff: RX: 0.01 MB, TX: 0.00 MB, Total: 0.01 MB
2014-03-21 11:37:48.012 cloneDevice sysmon loadavg: 0.01 0.03 0.00
2014-03-21 11:37:48.012 SYSMON sysmon loadavg: 0.01 0.03 0.00
2014-03-21 11:37:48.021 cloneDevice sysmon stat_cpu_percent: 1.30 0.00 1.12 97.43 0.00 0.02 0.13
2014-03-21 11:37:48.021 SYSMON sysmon stat_cpu_percent: 1.30 0.00 1.12 97.43 0.00 0.02 0.13
2014-03-21 11:37:48.032 cloneDevice sysmon ram: Total: 108.67 MB, Used: 78.54 MB, 72.28 %, Free: 30.13 MB
2014-03-21 11:37:48.032 SYSMON sysmon ram: Total: 108.67 MB, Used: 78.54 MB, 72.28 %, Free: 30.13 MB
2014-03-21 11:37:50.413 cloneDevice OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:50.413 OWTHERM OWX_28_6119BA030000 temperature: 15.875
2014-03-21 11:37:50.427 cloneDevice OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:50.427 OWTHERM OWX_28_6119BA030000 T: 15.88 °C
2014-03-21 11:37:50.440 cloneDevice OWX_28_6119BA030000 Temperatur: 15.88
2014-03-21 11:37:50.440 OWTHERM OWX_28_6119BA030000 Temperatur: 15.88

- komplette definition des Moduls mit den gesetzten attr

cloneDummy kann nur auf die Events zugreifen, die z.B. FHEM2FHEM liefert. diese findest Du im Eventmonitor!
Hier steht weder ein state noch ein STATE drinnen. Das bedeutet, der Nutzer von cloneDummy muss über das stateFormat dem Device cloneDummy <name> mitteilen, was im STATE stehen soll
Als Beispiel:

Code Auswählen Erweitern

define Bad cloneDummy FS_Bad
attr Bad room Bad
attr Bad stateFormat {sprintf("T: %.1f H: %.1f D: %.1f A: %.1f",ReadingsVal("Bad","Temperatur",0), ReadingsVal("Bad","Feuchte",0), ReadingsVal("Bad","dewpoint",0), ReadingsVal("Bad","absFeuchte",0))}


Gruß Joachim