Autor Thema: [14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen  (Gelesen 18874 mal)

Offline killah78

  • Full Member
  • ***
  • Beiträge: 250
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #30 am: 17 November 2019, 12:02:12 »
Ja genau das ist er. Der ist aber dauerhaft so günstig.
Temperatur entspricht meinen anderen Sensoren. Luftfeuchtigkeit zeigen bei mir 3 Sensoren in einem Raum alle was anderes an. Welcher davon jetzt passt kann ich nicht sagen. Andere zeigen 16 und 25% an, der NC3982 zeigt 40 an.

Gruss
killah78

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #31 am: 20 November 2019, 23:25:22 »
Ich habe die Device specific help angepasst und ergänzt.
Bitte mal drüberschauen ob es so passt. Die englische habe ich nur mit google übersetzt.

https://github.com/Ralf9/14_CUL_TCM97001/commit/d4b99688822b1d1b514ce4efb629b08ec3412780

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #32 am: 21 November 2019, 19:08:28 »
Wenn nichts dagegen spricht, habe ich vor bei der Erkennung neuer Sensoren bei der Reihenfolge der Abfragen AURIOL und KW9010 zu tauschen:

alt
if (($readedModel eq "AURIOL" || $readedModel eq "Unknown")) {

if (checkCRCKW9010($msg) == TRUE && ($readedModel eq "Unknown" || $readedModel eq "KW9010")) {

if ($readedModel eq "Auriol_IAN" || (hex($a[9]) >= 1 && hex($a[9] <= 3 && $readedModel eq "Unknown"))) {

if (($readedModel eq "TCM218943" || $readedModel eq "Unknown")) {


neu
if (checkCRCKW9010($msg) == TRUE && ($readedModel eq "Unknown" || $readedModel eq "KW9010")) {

if (($readedModel eq "AURIOL" || $readedModel eq "Unknown")) {

if ($readedModel eq "Auriol_IAN" || (hex($a[9]) >= 1 && hex($a[9] <= 3 && $readedModel eq "Unknown"))) {

if (($readedModel eq "TCM218943" || $readedModel eq "Unknown")) {

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Offline muede

  • New Member
  • *
  • Beiträge: 12
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #33 am: 30 November 2019, 10:25:51 »
Hallo,

auch ich habe mir in einem guten Angebot die Lidl Wetterstation geholt.
Leider habe ich noch einige Ungereimtheiten bei der Auswertung der Daten.
Zunächst zur Einrichtung:
  • Der Windsensor wird als CUL_TCM97001_181 erkannt. Dabei wird er als model W132 initialisiert. Die angezeigten Werte passen auch soweit. Stelle ich das Modell auf Auriol um, was es ja eigentlich auch ist, wird die Temperatur verändert und negativ angezeigt. Es handelt sich dabei aber nicht um eine einfache Umekhr des Vorzeichens. Es wird auch ein komplett abweichender Zahlenwert gesetzt (Bsp: gemssen als W132 9,6° C, umgesetzt als Auriol -15,6° C)
  • Der Regensensor wird als CUL_TCM97001_176. Er wird als model W174 initialisiert. Mit Umsetellung auf Auriol findet hier kein Datenaustausch statt. Unter 174 werden nur drei Werte angezeigt: rain, R und israining.

    battery        ok 2019-11-12 16:45:59
    batteryState ok 2019-11-12 16:45:59
    israining      no 2019-11-17 21:27:20
    rain          11.5 2019-11-17 21:26:42
    state    R: 11.5 2019-11-17 21:26:42

    Israining wird nur kurz als YES erkannt, um dann kurz später wieder auf NO umzuspringen, obwohl es am Regnen ist.
    Rain ist nur ein Summenzug. Die Readings des Mouls (oldRain, newRain) werden nicht angezeigt, die Differenz als 0 gewertet.

    2019.11.17 21:21:47 4: sduino: CUL_TCM97001 Parse Name: W174_176 , devicecode: CUL_TCM97001_176 , Model defined: W1742019.11.17 21:21:47 4: sduino: CUL_TCM97001 W174_176 old rain 11.25, age 35500, new rain 11.25, diff rain 0.0
    2019.11.17 21:21:47 4: sduino: CUL_TCM97001 W174_176 max difference rain 592.7 l
    2019.11.17 21:22:24 4: sduino: CUL_TCM97001 Parse Name: W174_176 , devicecode: CUL_TCM97001_176 , Model defined: W174
    2019.11.17 21:22:24 4: sduino: CUL_TCM97001 W174_176 old rain 11.25, age 35537, new rain 11.25, diff rain 0.0
    2019.11.17 21:22:24 4: sduino: CUL_TCM97001 W174_176 max difference rain 593.3 l
    2019.11.17 21:23:01 4: sduino: CUL_TCM97001 Parse Name: W174_176 , devicecode: CUL_TCM97001_176 , Model defined: W174
    2019.11.17 21:23:01 4: sduino: CUL_TCM97001 W174_176 old rain 11.25, age 35574, new rain 11.25, diff rain 0.0
    2019.11.17 21:23:01 4: sduino: CUL_TCM97001 W174_176 max difference rain 593.9 l

Auch ein Löschen der Device und erneute Einrichtng hat keine Änderung am Verhalten ergeben. Insbesondere der Regensensor ist so nicht sinnvoll zu verwenden. Meine Idee, mit israining die Markise zu steuern, ist so nicht möglich.

Hat jemand eine Idee, woran das liegen könnte?

LG,
Detlef

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #34 am: 30 November 2019, 19:40:40 »
Zitat
Der Windsensor wird als CUL_TCM97001_181 erkannt. Dabei wird er als model W132 initialisiert. Die angezeigten Werte passen auch soweit. Stelle ich das Modell auf Auriol um, was es ja eigentlich auch ist, wird die Temperatur verändert und negativ angezeigt.
W132 und W174 sollte eigentlich passen, das Modell Auriol ist für ältere Sensoren mit nur Temperatur.

Zitat
Israining wird nur kurz als YES erkannt, um dann kurz später wieder auf NO umzuspringen, obwohl es am Regnen ist.
Damit Israining länger als YES angezeigt wird, muss es so stark regnen, daß sich bei jeder gesendeten Nachricht das rain erhöht.

Gruß Ralf



FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #35 am: 01 Dezember 2019, 12:58:19 »
ich habe das model Auriol Z31743B ergänzt:
https://github.com/Ralf9/14_CUL_TCM97001/commit/0bddd595072cc60511085b4029560ef76c35f120

zum Testen dies ins FHEM Verzeichnis kopieren und dann einen fhem neustart
https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/FHEM/14_CUL_TCM97001.pm

version CUL_TCM97001
14_CUL_TCM97001.pm 18358 2019-11-30 17:00:00Z Ralf9

Ich habe folgendes geändert und ergänzt:
- Neues Attribut max-diff-rain, mit 0 (default) wird die Abfrage der rain Differenz zwischen 2 Messwerten deaktiviert.
- Korrektur der Berechnung von windSpeed, windGuest und windDirection.
- Neues Attribut windDirectionInverse, falls der Windmesser falsch herum montiert wurde.
- Neues Model "Auriol_IAN" (NC-3982, ADE WS 1503, Tchibo 65 722) zugefügt,
- Neues Model "TCM218943" zugefügt
- Neues Attribut "negation-batt", damit kann das Battery reading invertiert werden
- Einige Checksum Routinen optimiert und Log Ausgaben vereinheitlicht und optimiert.
- Es gibt nun für das Prologue Protokoll einen alternativen devicecode (DEF) bei dem als longID die 2. und 3. Hexiffer verwendet wird.
- Model Auriol Z31743B zugefügt
- update Device specific help ergänzt

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Pfriemler

  • Hero Member
  • *****
  • Beiträge: 3871
  • geht nich gips nich
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #36 am: 03 Dezember 2019, 12:32:14 »
Ausgehend von einer Anfrage zum optimalen Vorgehen bei Batteriewechsel:
https://forum.fhem.de/index.php/topic,105934.0.html
äußere ich hier erneut meinen Vorschlag, einen Mechanismus zum Batteriewechsel ähnlich wie er bei LaCrosse (und weiteren?) vorgesehen ist: es wurde ein "replaceBatteryForSec" implementiert, mit dem man FHEM mitteilen kann, dass eine in dieser Zeit neu auftauchende ID keinen autocreate-Vorgang auslöst, sondern diese ID diesem Device zugeordnet wird... Sollte man hier auch einpflanzen. Alerdings gibt es m.W. noch gar keine sets in dieser TYPE...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline yersinia

  • Hero Member
  • *****
  • Beiträge: 1006
    • Cyanide & Happiness
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #37 am: 03 Dezember 2019, 17:58:23 »
zum Testen dies ins FHEM Verzeichnis kopieren und dann einen fhem neustart
https://raw.githubusercontent.com/Ralf9/14_CUL_TCM97001/dev/fhem/FHEM/14_CUL_TCM97001.pm

version CUL_TCM97001
14_CUL_TCM97001.pm 18358 2019-11-30 17:00:00Z Ralf9
Getestet und funktioniert bei mir. Die Prologue bekommen die alternative DEF, bestehende Prologue Devices sind nicht (negativ) eingeschränkt. Läuft. Danke.
viele Grüße, yersinia
----
FHEM 6.0 (SVN) on RPi 4B with RasPi OS Buster (perl 5.28.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@aculfw | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #38 am: 04 Dezember 2019, 00:19:27 »
Zitat
äußere ich hier erneut meinen Vorschlag, einen Mechanismus zum Batteriewechsel ähnlich wie er bei LaCrosse (und weiteren?) vorgesehen ist: es wurde ein "replaceBatteryForSec" implementiert, mit dem man FHEM mitteilen kann, dass eine in dieser Zeit neu auftauchende ID keinen autocreate-Vorgang auslöst, sondern diese ID diesem Device zugeordnet wird...
Ich möchte erst mal nach einer Testphase den aktuellen Stand durch Bjoern in das SVN bringen.
Danach können wir das gerne angehen, da brauche ich aber Hilfe.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #39 am: 28 Dezember 2019, 14:26:01 »
Zitat
Ich möchte erst mal nach einer Testphase den aktuellen Stand durch Bjoern in das SVN bringen.
Da sich bis jetzt keiner wegen Probleme oder Fehler gemeldet hat, gehe ich davon aus, daß dies so passt.

Der aktuelle Stand ist im SVN und müsste ab morgen im fhem update sein

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline killah78

  • Full Member
  • ***
  • Beiträge: 250
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #40 am: 03 Januar 2020, 13:50:10 »
Hallo Ralf,
danke für deine Änderungen.
noch ein kurzes Feedback: ich hatte mich seit einigen Tagen (sind wohl schon Wochen) gewundert, dass ein Pearl NC-7159 Temperatursensor ein low-bat gesendet hat. Im Display war nichts derartiges sichtbar.
Jetzt habe ich aber gesehen, dass du ein Negation-batt implementiert hast. Dies musste ich für den Sensor setzen und alles ist gut.
Also keine Probleme.
Danke für deine Mühen.
Gruss
killah78

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #41 am: 08 Januar 2020, 19:13:13 »
Ausgehend von einer Anfrage zum optimalen Vorgehen bei Batteriewechsel:
https://forum.fhem.de/index.php/topic,105934.0.html
äußere ich hier erneut meinen Vorschlag, einen Mechanismus zum Batteriewechsel ähnlich wie er bei LaCrosse (und weiteren?) vorgesehen ist: es wurde ein "replaceBatteryForSec" implementiert, mit dem man FHEM mitteilen kann, dass eine in dieser Zeit neu auftauchende ID keinen autocreate-Vorgang auslöst, sondern diese ID diesem Device zugeordnet wird... Sollte man hier auch einpflanzen. Alerdings gibt es m.W. noch gar keine sets in dieser TYPE...
Ich habe es mir mal angeschaut wie es beim LaCrosse Modul funktioniert, dort gibt es ein newBatteryBit.

Für das 14_CUL_TCM97001 Modul müsste dies für Sensoren machbar sein die eine Taste zum manuellen Senden haben.
Die Nachrichten von diesen Sensoren müssen außerdem eindeutig z.B. über eine Prüfsumme dem Sensormodel zugeordnet werden können.

Es müsste dann nach einem Batteriewechsel innerhalb der replaceBatteryForSec Zeit die manuell Sendetaste mehrmals gedrückt werden.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Offline Pfriemler

  • Hero Member
  • *****
  • Beiträge: 3871
  • geht nich gips nich
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #42 am: 08 Januar 2020, 22:49:06 »
Dann ist das wohl ein bisschen anders als gedacht. Meines Wissens ändern die LaCrosse bei jedem Batteriewechsel ihre ID; es mag ja sein, dass sie ein newBatteryBit mitsenden. Anscheinend wird die ID eines auf "replaceBatteryForSec" gesetzten Sensors nur dann auf die neue korrigiert, wenn dieses Bit mitkommt. Willst Du das ersatzweise mit einer abweichenden Häufigkeit von Sendevorgängen erreichen?

Wenn jeder Sensor eine Prüfsumme mitschickt, die eine eindeutige Zuordnung zum Sensor ermöglicht, bräuchte es doch einen Batteriewechselmechanismus gar nicht ... ?

Ich selbst nutze nur einen einzigen TCM97001, aber ich habe offenbar ein paar Nachbarn - einige der Sender liefern plausible Werte für einen Einsatz im Freien oder unter einer Überdachung. Gerade ist es recht ruhig, die meisten sind nur "defined", zwei ominöse Sensoren sehen aus wie Schnappschüsse meines Sensors. Ich halte diese Neukreationen schlicht für Datenübermittlungsfehler.
Bei einem Batteriewechsel muss ich diesen Sensor neu einrichten; eine Taste hat er nicht.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3703
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #43 am: 09 Januar 2020, 19:26:20 »
Zitat
Willst Du das ersatzweise mit einer abweichenden Häufigkeit von Sendevorgängen erreichen?
Nein, diese Sensoren haben ein reading "mode", wenn am Sensor die Sendetaste gedrückt wird, wechselt es von normal auf forced.

Zitat
Wenn jeder Sensor eine Prüfsumme mitschickt, die eine eindeutige Zuordnung zum Sensor ermöglicht, bräuchte es doch einen Batteriewechselmechanismus gar nicht ... ?
Es wird über die gesendete Nachricht eine Prüfsumme gebildet und diese Prüfsumme mitgeschickt. Über die Art der Prüfsummenbildung lässt sich in der Regel das Sensormodel erkennen.

Bei Sensoren ohne NewBattery Bit oder Sendetaste habe ich keine Idee wie man das replaceBatteryForSec einbauen könnte.

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Offline HomeAuto_User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1040
Antw:[14_CUL_TCM97001.pm] Fehlerbehebungen, Wünsche und Ergänzungen
« Antwort #44 am: 09 Februar 2020, 11:55:17 »
Hallo Ralf,

beim W174 müsste man vermutlich eine Anpassung vornehmen.

Das Attribut

max-diff-rain 20

ist gesetzt aber dennoch passiert folgendes:

2020-02-08_10:57:14 W174_17 rain: 560.25
2020-02-08_11:27:27 W174_17 rain: 560.25
2020-02-08_11:57:40 W174_17 rain: 560.25
2020-02-08_11:58:55 W174_17 rain: 368.25
2020-02-08_11:59:31 W174_17 rain: 560.25
2020-02-08_12:29:44 W174_17 rain: 560.25
2020-02-08_12:59:57 W174_17 rain: 560.25

Das bringt jede Kurve zum knicken ;)
Das Verhalten tritt sporadisch auf.

Wie wäre es mit einem „OldValue“ Check oder die maxDiff vom Attribut darf nur positiv sein.

Liebe Grüße Marco


Gesendet von iPhone mit Tapatalk Pro
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

 

decade-submarginal