Mir ist gerade Folgendes aufgefallen:
Bei allen meinen SD_WS Typ 33 Devices werden bei aktivem Autocreate immer wieder die beiden Attribute:
event-min-interval und event-on-change-reading mit den Defaultwerten überschrieben.
Anbei ein List eines der Devices:
defmod SD_WS_33_TH_1 SD_WS SD_WS_33_TH_1
attr SD_WS_33_TH_1 DbLogInclude temperature,humidity
attr SD_WS_33_TH_1 IODev sduino
attr SD_WS_33_TH_1 alias SD_WS_33_TH_1
attr SD_WS_33_TH_1 comment Stadtpark: kleines Wohnzimmer oben
attr SD_WS_33_TH_1 event-min-interval .*:300
attr SD_WS_33_TH_1 event-on-change-reading .*
attr SD_WS_33_TH_1 group Temperatur & Luftfeuchte
attr SD_WS_33_TH_1 icon temperature_humidity
attr SD_WS_33_TH_1 model other
attr SD_WS_33_TH_1 room SD_WS,Stadtpark
attr SD_WS_33_TH_1 stateFormat {sprintf("T: %.1f H: %.1f D: %.1f",\
ReadingsVal($name,"temperature",0),\
ReadingsVal($name,"humidity",0),\
ReadingsVal($name,"dewpoint",0))}
Was mache ich falsch, bzw. wie kann man das abstellen ohne autocreate abzudrehen.
Gruß
Thomas
Ich glaube den Fehler gefunden zu haben:
Man darf das IODev-Attribut nicht setzen!
Hi,
wird das Attribut IODev nicht automatisch gesetzt?
event-min-interval und event-on-change-reading sind für SD_WS Typ 33 im Modul SD_WS hinterlegt.
Allerdings: "Sobald durch autocreate eine Gerätedefintion angelegt wird, auf den ein hier gelisteter Ausdruck passt, so werden die zugeordneten Optionen berücksichtigt."
Bedeutet, nur wenn Autocreate die Definition neu anlegt, sollten die Attribute gesetzt werden.
Kannst Du das Verhalten mit mehr Daten unterlegen? Also, die Definition haben wir. Dann nehme ich an, dass Du die Attribute löschst. Wie genau machst Du das?
Anschließend wird eine Nachricht vom Sensor empfangen und die Attribute sind wieder da?
Grüße Sidey
Hallo sidey,
ich habe das nochmal Stück für Stück versucht nachzustellen.
Daher antworte ich erst jetzt um ganz sicher zu sein.
Meine Vermutung hat sich als richtig herausgestellt,
Es hängt mit dem IODev zusammen, aber es wird auch nicht automatisch gesetzt.
Das hat einwandfrei funktioniert:
defmod SD_WS_33_TH_2 SD_WS SD_WS_33_TH_2
attr SD_WS_33_TH_2 DbLogInclude temperature,humidity
attr SD_WS_33_TH_2 alias SP.KU.TH
attr SD_WS_33_TH_2 comment Stadtpark: Kueche
attr SD_WS_33_TH_2 event-min-interval humidity:600,temperature:300
attr SD_WS_33_TH_2 event-on-change-reading batteryState,humidity:1,temperature:0.5
attr SD_WS_33_TH_2 group Temperatur & Luftfeuchte
attr SD_WS_33_TH_2 icon temperature_humidity
attr SD_WS_33_TH_2 model other
attr SD_WS_33_TH_2 room SD_WS,Stadtpark
attr SD_WS_33_TH_2 stateFormat {sprintf("T: %.1f H: %.1f D: %.1f",\
ReadingsVal($name,"temperature",0),\
ReadingsVal($name,"humidity",0),\
ReadingsVal($name,"dewpoint",0))}
Aber sobald ich IODev manuell für das Device setze, schlägt autocreate zu und macht mir das daraus:
defmod SD_WS_33_TH_2 SD_WS SD_WS_33_TH_2
attr SD_WS_33_TH_2 DbLogInclude temperature,humidity
attr SD_WS_33_TH_2 IODev sduino
attr SD_WS_33_TH_2 alias SP.KU.TH
attr SD_WS_33_TH_2 comment Stadtpark: Kueche
attr SD_WS_33_TH_2 event-min-interval .*:300
attr SD_WS_33_TH_2 event-on-change-reading .*
attr SD_WS_33_TH_2 group Temperatur & Luftfeuchte
attr SD_WS_33_TH_2 icon temperature_humidity
attr SD_WS_33_TH_2 model other
attr SD_WS_33_TH_2 room SD_WS,Stadtpark
attr SD_WS_33_TH_2 stateFormat {sprintf("T: %.1f H: %.1f D: %.1f",\
ReadingsVal($name,"temperature",0),\
ReadingsVal($name,"humidity",0),\
ReadingsVal($name,"dewpoint",0))}
Jetzt könnte man natürlich sage, dann lass das doch mit dem IODev einfach sein, aber was wenn man mehr als einen signalduino Empfänger betreiben möchte?
Gruß Thomas
Hi,
Danke für die ausführliche Darstellung.
Hast Du eine der Nachrichten, welche dazu führt, dass aus der 1. Definition die 2. wird?
Das IODev wird eigentlich nur für den Versand benötigt, was bei dem Sensor nicht implementiert ist.
Ich würde aber dennoch gern verstehen, wieso autocreate die Definition ändert.
Grüße Sidey
Ok, ich versuche ml diese Nachricht herauszufiltern.
Noch ein Nachtrag:
Nachdem das autocreate die beiden Attribute geändert hat, werden auf diesem Device gar keine Nachrichten mehr empfangen.
Das manuelle Löschen des IODev bringt dann auch keine Änderung mehr mit sich.
Nur wenn ich das Device komplett lösche und automatisch neu anlegen lasse, empfange ich wieder Werte.
Ich hoffe das ist der richtige Teil:
2020-04-04 10:06:24 Global global UNDEFINED SD_WS_33_TH_2 SD_WS SD_WS_33_TH_2
2020.04.04 10:06:25 4 : sduino: Read, msg READredu: MS;P1=514;P2=-2118;P3=-4093;P4=-8108;D=14121212131213121312131212121313121213121312121213131212121212121213121212121213121212;CP=1;SP=4;R=16;O;m0;
2020.04.04 10:06:25 4 : sduino: Parse_MS, Matched MS Protocol id 33 -> weather
2020.04.04 10:06:25 4 : sduino: Parse_MS, Decoded matched MS Protocol id 33 dmsg W33#15465180820 length 44 RSSI = -66
2020.04.04 10:06:25 4 : sduino: Dispatch, W33#15465180820, Dropped due to short time or equal msg
2020.04.04 10:06:25 4 : sduino: Parse_MS, Matched MS Protocol id 33.2 -> Tchibo
2020.04.04 10:06:25 4 : sduino: Parse_MS, Decoded matched MS Protocol id 33.2 dmsg W33#15465180820 length 44 RSSI = -66
2020.04.04 10:06:25 4 : sduino: Dispatch, W33#15465180820, Dropped due to short time or equal msg
2020.04.04 10:06:26 4 : sduino: Read, msg READredu: MS;P1=508;P2=-2070;P3=-4096;P4=-8108;D=14121212131213121312131212121313121213121312121213131212121212121213121212121213121212;CP=1;SP=4;R=16;
2020.04.04 10:06:26 4 : sduino: Parse_MS, Matched MS Protocol id 33 -> weather
2020.04.04 10:06:26 4 : sduino: Parse_MS, Decoded matched MS Protocol id 33 dmsg W33#15465180820 length 44 RSSI = -66
2020.04.04 10:06:26 4 : sduino: Dispatch, W33#15465180820, Dropped due to short time or equal msg
2020.04.04 10:06:26 4 : sduino: Parse_MS, Matched MS Protocol id 33.2 -> Tchibo
2020.04.04 10:06:26 4 : sduino: Parse_MS, Decoded matched MS Protocol id 33.2 dmsg W33#15465180820 length 44 RSSI = -66
2020.04.04 10:06:26 4 : sduino: Dispatch, W33#15465180820, Dropped due to short time or equal msg
2020.04.04 10:06:29 4 : sduino: Read, msg READredu: MS;P0=-4138;P1=492;P2=-2086;P3=-8186;D=13121210101212121010101212121212121210121012121210101212121010121210121212121212121010;CP=1;SP=3;R=254;O;m2;
2020.04.04 10:06:29 4 : sduino: Parse_MS, Matched MS Protocol id 33 -> weather
2020.04.04 10:06:29 4 : sduino: Parse_MS, Decoded matched MS Protocol id 33 dmsg W33#31C0518C80C length 44 RSSI = -75
2020.04.04 10:06:29 4 : sduino: SD_WS_Parse protocol 33, rawData 31C0518C80C
2020.04.04 10:06:29 4 : sduino: SD_WS_Parse decoded protocol-id 33 (E0001PA, s014, S522, TCM, TFA 30.3200, TX-EZ6), sensor-id 199
2020.04.04 10:06:29 4 : sduino: Parse_MS, Matched MS Protocol id 33.2 -> Tchibo
2020.04.04 10:06:29 4 : sduino: Parse_MS, Decoded matched MS Protocol id 33.2 dmsg W33#31C0518C80C length 44 RSSI = -75
2020.04.04 10:06:29 4 : sduino: Dispatch, W33#31C0518C80C, Dropped due to short time or equal msg
2020.04.04 10:06:29 4 : sduino: Read, msg READredu: MS;P0=-4154;P1=491;P2=-2090;P3=-8194;D=13121210101212121010101212121212121210121012121210101212121010121210121212121212121010;CP=1;SP=3;R=254;O;m1;
2020.04.04 10:06:29 4 : sduino: Parse_MS, Matched MS Protocol id 33 -> weather
Nachvollziehen konnte ich das schon mal. Sobald das Attribut "IODev" gesetzt ist, wird immer wieder ein "autocreate" gestartet:
2020.04.04 11:33:11 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:35:50 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:35:50 2: autocreate: define FileLog_SD_WS_33_T_2 FileLog ./log/SD_WS_33_T_2-%Y-%m.log SD_WS_33_T_2
2020.04.04 11:35:50 2: autocreate: define SVG_SD_WS_33_T_2 SVG FileLog_SD_WS_33_T_2:temp4:CURRENT
2020.04.04 11:36:43 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:39:23 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:39:23 2: autocreate: define FileLog_SD_WS_33_T_2 FileLog ./log/SD_WS_33_T_2-%Y-%m.log SD_WS_33_T_2
2020.04.04 11:39:23 2: autocreate: define SVG_SD_WS_33_T_2 SVG FileLog_SD_WS_33_T_2:temp4:CURRENT
2020.04.04 11:40:15 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:41:08 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:41:08 2: autocreate: define FileLog_SD_WS_33_T_2 FileLog ./log/SD_WS_33_T_2-%Y-%m.log SD_WS_33_T_2
2020.04.04 11:41:08 2: autocreate: define SVG_SD_WS_33_T_2 SVG FileLog_SD_WS_33_T_2:temp4:CURRENT
2020.04.04 11:42:01 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:42:54 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
2020.04.04 11:42:54 2: autocreate: define FileLog_SD_WS_33_T_2 FileLog ./log/SD_WS_33_T_2-%Y-%m.log SD_WS_33_T_2
2020.04.04 11:42:54 2: autocreate: define SVG_SD_WS_33_T_2 SVG FileLog_SD_WS_33_T_2:temp4:CURRENT
2020.04.04 11:44:40 1: sduinoIP: SD_WS_Parse UNDEFINED sensor SD_WS_33_T detected, code SD_WS_33_T_2
Zitat von: Papaloewe am 04 April 2020, 09:11:04
Jetzt könnte man natürlich sage, dann lass das doch mit dem IODev einfach sein, aber was wenn man mehr als einen signalduino Empfänger betreiben möchte?
Muss denn ein anderes Device angelegt werden, wenn der Sensor von einem anderen Empfänger ausgewertet wird?
Dafür war das Attribut in einem anderen Modul ursprünglich mal gedacht, wenn verschiedene Sensoren mit gleicher Adresse, aber verschiedenen Empfangsfrequenzen ausgewertet werden sollten.
Ich wollte eigentlich, zur besseren Funkausleuchtung (Garten) einen zweiten Empfänger (Signalesp) in Betrieb nehmen und dachte man könnte über IODev steuern, welches Device von welchem Empfänger empfangen wird. Das scheint nicht so unterstützt zu werden.
Es macht keinen Sinn, dass zwei Empfänger, zwei identische Devices anlegen. Das wollte ich damit auch nicht erreichen.
Ist jetzt auch kein großes Problem, aber es sollte nicht solche Nebeneffekte bewirken, meine ich.
Gruß
Thomas
So ganz lang ich mit meinem Versuch auch nicht falsch:
aus der FHEM Referenz:
ZitatAllgemeine Attribute
Die folgenden lokalen Attribute werden von mehreren Geräten verwendet:
IODev
Setzt das IO oder das physische Device, welches zum Senden der Signale an dieses logische Device verwendet werden soll (Beispielsweise FHZ oder CUL). Hinweis: Beim Start weist FHEM jedem logischen Device das letzte physische Device zu, das Daten von diesem Typ empfangen kann. Das Attribut IODev muss nur gesetzt werden, wenn mehr als ein physisches Device fähig ist, Signale von diesem logischen Device zu empfangen.
Wieso wäre es denn ein Problem, wenn beide Empfänger den gleichen Sensor auswerten?
Vielleicht mache ich mir auch einen Kopf, wo gar kein Problem ist?
Ich dachte nur, wenn ein Empfänger mangels Reichweite nur Müll empfängt, aber ein zweiter guten Empfang hat, dann könnte man das gezielt beeinflussen.
Gruß
Thomas
Spätesten beim Senden kommt es aber doch zu Problemen, bzw. zu Doppelbefehlen, oder?
Wie oder was willst du denn bei einem Sensor senden? Ein Sendebefehl ist bei Sensoren in FHEM nicht vorgesehen.
Mehrere Empfänger, die das gleiche Signal empfangen stellen kein Problem dar. Ich habe hier z.B. drei Empfänger die u.a. diesen Sensor auswerten:
sduinoACM_DMSG TXA06465265D
sduinoACM_MSGCNT 110
sduinoACM_Protocol_ID 66
sduinoACM_RSSI -55.5
sduinoACM_TIME 2020-04-05 13:26:31
sduinoIP_DMSG TXA06465265D
sduinoIP_MSGCNT 124
sduinoIP_Protocol_ID 66
sduinoIP_RSSI -35.5
sduinoIP_TIME 2020-04-05 13:25:32
sduinoUSB0_DMSG TXA06465265D
sduinoUSB0_MSGCNT 130
sduinoUSB0_Protocol_ID 66
sduinoUSB0_TIME 2020-04-05 13:26:32
Senden will ich natürlich nicht an Sensoren, aber z.B. an schaltbare Steckdosen.
Dann setzt du das Attribut IODev ja bei den Fernbedienungen bzw. Steckdosen, aber nicht beim Temperatur-/Feuchtesensor.
Ich habe den Fehler jetzt behoben. Das Attribut "IODev" gibt es jetzt bei diesen Sensoren nicht mehr. Du könntest das bitte testen, in dem du folgendes Update durchführst:
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34_IODev/controls_signalduino.txt
Vielen Dank.
Hi Papalöwe,
Funktioniert die Anpassung wie gewünscht?
Grüße Sidey
Ja, das Attribut steht jetzt nicht mehr zur Auswahl, was auch richtig ist solange es nicht unterstützt wird, bzw. es an dieser Stelle auch keinen Sinn macht.
Insofern ist aus meiner Sicht die Sache erledigt.
Gruß
Thomas
Die Anpassung ist ab Morgen im normalen FHEM Update enthalten. Danke für deine Unterstützung bei der Fehlersuche.