CUL_TCM97001 - Patch

[Sidey]

Hi Björn,


ich hab einen Patch für dein Modul erstellt.
Bitte mal sichten.

Hauptsächlich ging es mir darum, dass man Sensoren auch ohne ihre Zufalls ID anlegen kann und dafür nur den Kanal nutzt.
Solange man nicht mehr Geräte als Kanäle hat, klappt das ja auch.
Das habe ich für NC_WS und TCM97001 implementiert.

Damit das dann auch Geräteübergreifend klappt, habe ich die Geräte vom Typ NC_WS und TCM97001 dann auch nach dem Modell und nicht wie bisher nach dem namen des Modules benannt.

Zusätzlich habe ich das unknown Device auch umbenannt und für alle drei Geräte auch angepasste Autocreate Einstellungen definiert.

Damit keine bereits Vorhandenen NC_WS oder TCM97001 Geräte neu angelegt werden, habe ich eine Prüfung eingebaut.
Wer auf die neue Namensgebung umstellen möchte, müsste das Gerät vorher erst löschen.


Sofern dir das ganze zusagt, müsste es natürlich auch noch für die anderen Sensoren nachgeholt werden.


Grüße Sidey

[bjoernh]

Hi Björn,


ich hab einen Patch für dein Modul erstellt.
Bitte mal sichten.

Hauptsächlich ging es mir darum, dass man Sensoren auch ohne ihre Zufalls ID anlegen kann und dafür nur den Kanal nutzt.
Solange man nicht mehr Geräte als Kanäle hat, klappt das ja auch.
Das habe ich für NC_WS und TCM97001 implementiert.

Damit das dann auch Geräteübergreifend klappt, habe ich die Geräte vom Typ NC_WS und TCM97001 dann auch nach dem Modell und nicht wie bisher nach dem namen des Modules benannt.

Zusätzlich habe ich das unknown Device auch umbenannt und für alle drei Geräte auch angepasste Autocreate Einstellungen definiert.

Damit keine bereits Vorhandenen NC_WS oder TCM97001 Geräte neu angelegt werden, habe ich eine Prüfung eingebaut.
Wer auf die neue Namensgebung umstellen möchte, müsste das Gerät vorher erst löschen.


Sofern dir das ganze zusagt, müsste es natürlich auch noch für die anderen Sensoren nachgeholt werden.


Grüße Sidey

Hallo,

ich hab mir die Änderungen jetzt mal angesehen.
Für was ist denn das Attribut longids? So wie ich es sehe willst Du die Umschaltung auf die alten IDs ermöglichen, oder war das nur für die Abwärtskompatibilität gedacht?
Die Idee mit den kurzen IDs ist ja im Prinzip gut, allerdings höre ich jetzt schon die ersten aufschreien. Einige haben mehrere von den Eurochrons gekauft, wenn man diese nun auf den Kanal beschränkt bekommt man Probleme.
Selbst bei mir zu Hause funken in der Umgebung viele gleichen Modelle.
Was meinst Du bzw. die anderen dazu?

Gruß
Björn

[chris1284]

ich habe diverse ws0002 im einsatz (7 stück, model NC_WS). mit channel würden nur 3 gehen (und dann evtl nicht mal die eigenen wenn der nachbar auch welche auf dme gleichen channel hat oder?).
wenn man es sich aussuchen kann ob man lange, zufällige ids oder kurze / channels nimmt sollte es egal sein. das mit dem channel hat doch nur den vorteil beim batteriewechsel oder?
das

Hauptsächlich ging es mir darum, dass man Sensoren auch ohne ihre Zufalls ID anlegen kann und dafür nur den Kanal nutzt.

sehe ich nicht ganz als feature da per autocreate eh alles automatisch angelegt wird, was noch weniger arbeit bedeutet

[Sidey]

Hi,

Das Attribut longid ist in einigen Modulen bereits seit Jahren definiert.
Über das Attribut kann der Anwender steuern, ob seine Sensoren mit oder ohne Zufalls ID definiert werden.

Autocreate legt die Sensoren zwar grundsätzlich an, aber wenn man die Geräte noch in diversen Funktionen einbindet, dann ist es manchmal nervig, wenn sich der Name ändert. Umbenennen ist natürlich möglich.

Wer mehr Sensoren als Kanäle  hat, kann seine Sensoren ja weiterhin mit zufalls IDs anlegen lassen. Alle anderen können den Komfort nutzen, dass es über den Kanal definiert wird und sich der Name nicht mehr ändert.

Grüße Sidey
   

[bjoernh]

Hi,

Das Attribut longid ist in einigen Modulen bereits seit Jahren definiert.
Über das Attribut kann der Anwender steuern, ob seine Sensoren mit oder ohne Zufalls ID definiert werden.

Autocreate legt die Sensoren zwar grundsätzlich an, aber wenn man die Geräte noch in diversen Funktionen einbindet, dann ist es manchmal nervig, wenn sich der Name ändert. Umbenennen ist natürlich möglich.

Wer mehr Sensoren als Kanäle  hat, kann seine Sensoren ja weiterhin mit zufalls IDs anlegen lassen. Alle anderen können den Komfort nutzen, dass es über den Kanal definiert wird und sich der Name nicht mehr ändert.

Grüße Sidey

Hallo Sven,

ok, ich verstehe deinen Wunsch und den Mehrwert. Jetzt habe ich nur das Problem, dass der CUL das Attribut longids nicht kennt.
Da muss also Rudi jetzt das CUL-Modul erweitern.
So wie es es sehe muss es eh gemacht werden, das Oregon Modul verwendet auch das Attribut longids und dieses spreche ich bereits bei mir lokal via dem CUL_REDIRECT an.

Mir ist gerade noch aufgefallen, dass die Doku vom SignalDuino nicht stimmt:

# Use any long IDs for all devices (this is default):
attr sduino longids 1

So wie ich es aber sehe, ist der Default z.B. im SD_WD07 == 0

Ist das so gewollt?


Und noch was 
Ich finde das SD_WD07 Modul ist ziemlich gesprächig:

Code Auswählen Erweitern


2015.11.19 20:40:21 3: SD_WS07 converted to bits: 01010011 1 010 000011100001 1111 01000001
2015.11.19 20:40:21 3: SD_WS07_TH decoded protocolid: 7 sensor id=53, channel=3, temp=22.5, hum=65, bat=ok
2015.11.19 20:40:21 3: SD_WS07 converted to bits: 01010011 1 010 000011100001 1111 01000001
2015.11.19 20:40:21 3: SD_WS07_TH decoded protocolid: 7 sensor id=53, channel=3, temp=22.5, hum=65, ba

Kannst Du da den Debuglevel höher drehen, 3 ist meines Wissens nach Standard.


Mhh ein Bug ist leider auch noch drinnen:
eingeschaltete LongIDs:

Code Auswählen Erweitern

Can't locate object method "_" via package "53" (perhaps you forgot to load "53"?) at ./FHEM/14_SD_WS07.pm line 136.
Danch ist Fhem abgestürzt.

Die Zeile:
$deviceCode=$model._$id.$channel;
muss in
$deviceCode=$model."_".$id.$channel;
geändert werden.

Gruß
Björn

[Sidey]

Hallo Sven,


Mir ist gerade noch aufgefallen, dass die Doku vom SignalDuino nicht stimmt:

# Use any long IDs for all devices (this is default):
attr sduino longids 1

So wie ich es aber sehe, ist der Default z.B. im SD_WD07 == 0

Ist das so gewollt?

Bevor ich was falsches sage. Ich schau mir das noch mal ganz genau an. Glaube dass es im Oregon Modul auch nicht so wie dokumentiert ist....

Und noch was 
Ich finde das SD_WD07 Modul ist ziemlich gesprächig:
Kannst Du da den Debuglevel höher drehen, 3 ist meines Wissens nach Standard.

Klar, ist noch aus der Entwicklungszeit. Ich setze alles auf 4 oder 5, bis auf das autocreate.

Mhh ein Bug ist leider auch noch drinnen:
eingeschaltete LongIDs:

Code Auswählen Erweitern

Can't locate object method "_" via package "53" (perhaps you forgot to load "53"?) at ./FHEM/14_SD_WS07.pm line 136.
Danch ist Fhem abgestürzt.

Danke. Hat wohl noch niemand bisher eingeschaltet. Fehler ist klar erkannt und wird behoben.

Grüße Sidey

[bjoernh]

Eine Unschönheit ist mir jetzt beim ausprobieren noch aufgefallen.
Ich hab mal alle Protokolle auf meinem Testsystem auf die neue ID Methode umgestellt.
Der Punkt ist jetzt aber, dass das TCM_97001 Modul manchmal neue Sensoren anlegt, obwohl diese bereits als andere Sensoren angelegt wurden.
Der Grund ist, dass das Modul nach dem first Match prinzip arbeitet. Wenn nun ein Sensor zufälligerweise bei einem vorangegangenen Typ matched wird es neu angelegt.
Konkret z.B. stimmt die CRC von einem SD-WD07 zufällig mit dem eines TCM97.... überein.
Und dann wird der Sensor neu angelegt. Zukünftige empfangene Pakete werden dann immer beim zuerst erkannten bearbeitet.
Das ist echt doof.
Wenn ich aber die ID wieder wie früher TCM97001_<ZAHL> benenne, dann würde er erkennen, dass der Sensor bereits angelegt war und den falschen Typ überspringen.
Da muss ich mir jetzt echt noch was einfallen lassen. Evtl werde ich die a-culfw erweitern, so dass ich es im Modul schneller erkennen kann.

Danke. Hat wohl noch niemand bisher eingeschaltet. Fehler ist klar erkannt und wird behoben.

Naja, die wenigsten werden wohl die Doku lesen und das Attribut longids setzen. Zumal es nicht im Modul dokumentiert ist sondern im SignalDuino bzw. irgendwann im CUL

Ich bin mir aber immer noch nicht sicher ob es bei dem TCM Modul so Sinn macht. Das obige beschriebene Problem überwiegt meiner Meinung nach den Vorteilen.

[Sidey]

Der Grund ist, dass das Modul nach dem first Match prinzip arbeitet. Wenn nun ein Sensor zufälligerweise bei einem vorangegangenen Typ matched wird es neu angelegt.
Konkret z.B. stimmt die CRC von einem SD-WD07 zufällig mit dem eines TCM97.... überein.
Und dann wird der Sensor neu angelegt. Zukünftige empfangene Pakete werden dann immer beim zuerst erkannten bearbeitet.
Das ist echt doof.

Verstehe ich das jetzt richtig, dass das TCM_97001 Modul bereits ohne den Patch einen Sensor nicht eindeutig identifiziert?
Dazu fallen mir dann folgende Punkte ein:

1.  Wenn die Daten zum Sensor nicht auseinander gehalten werden können, dann trifft das doch heute auch schon zu. Folglich kann man den Auswertungscode eines Sensors bereits heute entfernen und legt die Sensoren, die mit dem gleichen Namen empfangen werden unter dem gleichen Kürzel an. Eventuell gibt es aber doch ein Unterscheidungsmerkmal, dann wertet man dieses aus.

2. Die Protokolle 7 und 1 (so habe ich die mal benannt, da mir nichts besseres einfällt) verwenden eine unterschiedliche Signalmodulierung. Daran kann man die auch sehr gut unterscheiden.

Eventuell habe ich auch etwas nicht richtig verstanden.

Grüße Sidey

[Sidey]

Hi Björn,

ich habe gesehen Du hast die Idee aufgegriffen und auch für alle anderen Sensoren umgesetzt.

Für den TCM97001 Sensor hat das allerdings nicht funktioniert.
Ich habe deshalb das Modell und auch den Autocreate Teil angepasst.

Edit:
Ich muss korrigieren. Mit dem Patch wird ein TCM97001 Sensor via autocreate angelegt, allerdings wird er nicht mit Werten aktualisiert.
Hast Du da eine Idee?


Grüße Sidey

[HomeAuto_User]

Hallo,
ich fasse mal bei diesem Thema fort, da ich nichts passendes im Forum fand.

Seit längerem erhalte ich immer einen CUL_TCM97001 welcher angelegt wird mit Werten.
Die Werte sind nicht plausibel und sehr variabel von Empfang zu Empfang.
Die Dekodierung kann nicht richtig sein, da absolut unplausible Werte herauskommen. Ist die Checksumme korrekt eingebunden?

2017-05-18_06:30:38 TCM97..._51 temperature: 18.1
2017-05-18_06:30:38 TCM97..._51 T: 18.1
2017-05-18_06:30:38 TCM97..._51 RSSI: -90
2017-05-18_06:30:38 TCM97..._51 DMSG: s3380B500E0
2017-05-18_06:30:38 TCM97..._51 RAWMSG: MS;P0=-636;P1=453;P2=-2035;P3=-4076;P4=-7932;P6=-272;P7=160;D=141212131312121313131212121212121213121313121312131210671;CP=1;SP=4;R=224;
2017-05-18_07:50:22 TCM97..._51 temperature: 56.9
2017-05-18_07:50:22 TCM97..._51 T: 56.9
2017-05-18_07:50:22 TCM97..._51 RAWMSG: MS;P1=-2020;P2=449;P3=-7952;P4=-4083;P5=-180;D=2321212424212124242421242121212421212124242421212421242421255;CP=2;SP=3;R=225;
2017-05-18_07:50:22 TCM97..._51 DMSG: s33A23960E1
2017-05-18_07:50:22 TCM97..._51 RSSI: -89.5
2017-05-18_08:35:13 TCM97..._51 temperature: 38.1
2017-05-18_08:35:13 TCM97..._51 T: 38.1
2017-05-18_08:35:13 TCM97..._51 DMSG: s33A17D40E1
2017-05-18_08:35:13 TCM97..._51 RAWMSG: MS;P0=-2045;P1=461;P3=-4116;P4=-7972;D=1410101313101013131310131010101013101313131313101310131010010;CP=1;SP=4;R=225;
2017-05-18_08:35:13 TCM97..._51 RSSI: -89.5

MfG