Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

[noansi]

Hallo mwllgr,

ja, im 00_TSCUL.pm in Zeile 805

Code Auswählen Erweitern

        Log3 ${$pname}, 1, tsculParseName.${$pname}." SlowRF receive timeout detected: ".${$prmsg};

die 1 auf den Wunschloglevel erhöhen.

Der Log Eintrag soll sagen, das auf SlowRf längere Zeit nichts empfangen wird. Wenn also kein regelmäßiger Sender gültig empfangen werden kann, dann kommt die Meldung.

Gruß, Ansgar.

[mwllgr]

Okay - dachte es geht vllt. über ein Attribut auch - aber gut, danke.
Muss mit dem CUL nämlich nur senden, da wird normalerweise nichts empfangen.

[noansi]

Hallo mwllgr,

die Anwendung hatte ich bisher nicht.
Aber in der nächsten Version wird der LogLevel dafür per Attribut einstellbar sein.

Gruß, Ansgar.

[pantau]

Hallo,

ich habe eine relativ umfangreiche Installation mit mehreren CUL und einem CUNX. Dies versuche ich jetzt nach und nach auf TSCUL umzustellen.
Dabei tritt nun folgendes Problem mit den SlowRF devices auf. Ich habe zuerst den CUNX umgeflasht und mit FHEM zum laufen gebracht (rcul). Dann wurden per autocreate etliche TSCUL_EM und TSCUL_WS devices angelegt. Nun habe ich einen CULv3 mit TSCUL geflasht und in FHEM an TSCUL eingebunden (CUL_0). Nun ist mein Log voll mit diesen Meldungen:
TSCUL_WS CUL_0 UNDEFINED temp/hum sensor detected, code 51
2020.01.04 14:21:15 2: autocreate: define FileLog_TSCUL_WS_51 FileLog ./log/TSCUL_WS_51.log TSCUL_WS_51:T:.*
2020.01.04 14:21:15 2: autocreate: define SVG_TSCUL_WS_51 SVG FileLog_TSCUL_WS_51:temp4hum6:CURRENT
D.h. TSCUL will alle Geräte die mit rcul angelegt werden noch einmal mit CUL_0 erzeugen. Erstens tut er es dann nicht, d.h. der Eintrag IODev bleibt auf rcul und die Meldung taucht immer wierder im Log auf, zweitens halte ich es nicht für sinnvoll bei einem IODev Wechsel alle Geräte neu anzulernen?

Zusätzlich hatte ich ein TSCUL_EM_6 in EM_xxx umbenannt. Das wurde jetzt mit dem neuen IODev wieder neu als TSCUL_EM_6 angelernt. Jetzt habe ich 2x das gleiche Gerät, mit verschiedenem IODev.

Ist das das gewünschte Verhalten, oder habe ich eine Einstellung übersehen?

P.S: Wenn ich das IODev händisch auf das neue CUL ändere ist für das Gerät Ruhe ...

Gruß

Peter

[noansi]

Hallo Peter,

doch mal ein SlowRf Nutzer.

Ist das das gewünschte Verhalten, oder habe ich eine Einstellung übersehen?

Ich denke im wesentlichen sagt der Code ja dazu und hängt damit zusammen, dass für die TSCUL_WS, TSCUL_EM, TSCUL_TX (und TSKS300) die Möglichkeit besteht, mehrere dieser Sensoren mit unterschiedlichem IODev zu nutzen und damit bei genügend räumlichem Abstand dem Code mehrfach nutzen zu können (CUL A empfängt nur Sensor A mit Code X und CUL B empfängt nur Sensor B mit ebenfalls Code X).

Mit dem Attribut IODev wird der jeweilige Sensor dann intern individuell per diesem IODev angelegt.

D.h. TSCUL will alle Geräte die mit rcul angelegt werden noch einmal mit CUL_0 erzeugen.

autocreate will das, nicht TSCUL.
Und eben, weil der jeweilige Sensor dem anderen CUL schon zugeordnet ist und somit der Sensor vom jeweilen TSCUL_XX Modul als "neu" gesehen wird.

Erstens tut er es dann nicht, d.h. der Eintrag IODev bleibt auf rcul

Tut autocreate nicht, weil des den automatisch generierten Namen aus Modulnamen und Code mitbekommt, der aber schon exisitert.

Wenn ich das IODev händisch auf das neue CUL ändere ist für das Gerät Ruhe ...

Das ist derzeit auch die Lösung dazu. Händisch das IODev bei Multiempfängersystem zuordnen.
Bzw. bei bestehender Konfiguration auch diese Sensordevices händisch auf TSCUL_XX in der fhem.cfg umstellen, was den bestehenden Devicenamen erhält. Da autcreate zunächst stört, erst mal abschalten.

Gruß, Ansgar.

[pantau]

Mit dem Attribut IODev wird der jeweilige Sensor dann intern individuell per diesem IODev angelegt.
autocreate will das, nicht TSCUL.
Und eben, weil der jeweilige Sensor dem anderen CUL schon zugeordnet ist und somit der Sensor vom jeweilen TSCUL_XX Modul als "neu" gesehen wird.

Hm, ich rüste ein bestehendes System um, die Devices und die Multiempfänger gab es schon "immer". Da hat autocreate aber nicht immer zugeschlagen. Da macht TSCUL doch den Unterschied.

Gerade getestet: In der Konfiguration ohne TSCUL kann ich ein CUL "weglassen" (oder es fällt aus oder ich zieh es ab im Betrieb). Dann sehe ich bei LastIODev das der Sensor noch über ein anderes IODev kommt. Sonst ändert sich nichts, kein autocreate im Log.
Mit TSCUL wird dann wieder für das nun empfangende Device ein "endloses" autocreate erzeugt.
Das spricht etwas gegen die mögliche Redundanz durch Multiempfänger und für ein "problem" bei TSCUL?
Getestet habe ich übrigens mit aktueller FHEM (von gestern) und Deinem und dem Original autocreate. Da ist das Verhalten gleich.

Wenn ich autocreate abschalte, habe ich immer noch haufenweise UNDEFINED Einträge im Log - unschön....

[noansi]

Hallo Peter,

hast Du eventuell "ignoreTypes" bei autocreate eingestellt, um CUL_WS_xx etc. zu ignorieren?

Das ist zumindest in den TSCUL_XX Modulen noch nicht drin.

Gruß, Ansgar.

[noansi]

Hallo Peter,

und es gibt noch eine kleine Gemeinheit in fhem.pl.

Dort gibt es (Zeile 2201 in aktueller Version):

Code Auswählen Erweitern

    $attr{$hn}{IODev} = $hash->{IODev}{NAME}
      if($hasIODevAttr && $hash->{TYPE} ne "CUL_WS");

Was für CUL_WS verhindert, dass automatisch ein IODev zugewiesen wird.

Das wäre zu ändern in:

Code Auswählen Erweitern

    $attr{$hn}{IODev} = $hash->{IODev}{NAME}
      if($hasIODevAttr && $hash->{TYPE} !~ /^(?:CUL_WS|TSCUL_WS|TSCUL_EM|TSCUL_TX|TSCUL_NC7427)$/);

Damit all diese Module nicht automatisch ein IODev zugeordnet bekommen.

Gruß, Ansgar.

[pantau]

Hallo Peter,

hast Du eventuell "ignoreTypes" bei autocreate eingestellt, um CUL_WS_xx etc. zu ignorieren?

Das ist zumindest in den TSCUL_XX Modulen noch nicht drin.

Gruß, Ansgar.

ignoreTypes sieht bei mir so aus
FHT_.*|CUL_FHTTK_.*|FS20.*

Das erklärt es dann wohl nicht?!

Gesendet von meinem SM-N9500 mit Tapatalk

[noansi]

Hallo Peter,

Das erklärt es dann wohl nicht?!

Aber die automatische Zuordnung eines IODev, siehe oben sollte es erklären.

Gruß, Ansgar.

[pantau]

Hallo Peter,
Aber die automatische Zuordnung eines IODev, siehe oben sollte es erklären.

Gruß, Ansgar.

Ich baue das morgen mal ein. Momentan stört mich das CUL_EM da nicht behandelt wird. Die werden auch nur mit TSCUL autocreatet. Ich schau mir mal den Code drum rum an.

Gesendet von meinem SM-N9500 mit Tapatalk

[noansi]

Hallo Peter,

ich habe hier https://forum.fhem.de/index.php/topic,107032.msg1008792.html#msg1008792 mal bei Rudolf angefragt, ob er diese spezielle CUL_WS Behandlung mal generischer implementieren möchte.
Dann könnte ich so eine generische Anpassung einfach in meinen Modulen ergänzen. Und auch andere Module anderer Entwickler könnten es nutzen.

Ein eigenes fhem.pl werde ich nicht hier rein packen. Sprich, wenn Rudolf nicht tätig wird, dann musst Du diese kleine händische Änderung in fhem.pl nach jedem FHEM Update neu vornehmen.
Oder eben für jedes SlowRf IO einen eigenes Sensordevice mit passendem IODev Attribut anlegen.

Ich schau mir mal den Code drum rum an.

Ich hab's bei mir in die fhem.pl eingebaut und getestet, dass es das Verhalten abstellt.
Sprich, ein Sensordevice wird angelegt und Ruhe ist dann mit den unbekannten devices und das eine Sensordevice bekommt alle seine Empfangstelegramme von den mehreren Empfängern.

Wenn dann das Atrribut IODev beim Sensordevice definiert wird, dann wird es auch speziell für die Empfangsdaten für das IO. Und das will ich selber auch so haben. Da setzt meine Empfangsstatistik für die IOs drauf auf.

Gruß, Ansgar.

[pantau]

Hallo Ansgar,
vielen Dank fuer die schnellen und ausfuehrlichen Antworten!

Ich hab's bei mir in die fhem.pl eingebaut und getestet, dass es das Verhalten abstellt.
Sprich, ein Sensordevice wird angelegt und Ruhe ist dann mit den unbekannten devices und das eine Sensordevice bekommt alle seine Empfangstelegramme von den mehreren Empfängern.

Im Prinzip ja, aber
- erst nachdem ich alle schon angelegten TSCUL_* noch mal geloescht habe. (Ich hatte probehalber schon vorher versucht einfach das attr IODEV zu loeschen, das hatte aber keinen Effekt)
- in Internals steht jetzt als IODev bei mir bei allen Devices TS_CUL_RFR_02. Wird da einfach immer das letzte definierte TSCUL eingetragen? (LastInputDev ist unterschiedlich)
- wenn ich ein rename eines Devices mache (z.B. rename TSCUL_EM_6 EM_Pati), dann wird beim naechsten Empfang wieder ein TSCUL_EM_6 angelegt und EM_Pati wird nicht mehr aktualisiert
Den letzten Punkt halte ich fuer "suboptimal". Ist das ein Nebeneffekt der fhem.pl Aenderung? Zumindest hat das Umbenennen noch vor der Aenderung geklappt.... Waere fuer mich ein Killerkriterium, wenn ich Devices nicht umbennen koennte - trotz Deiner ausgezeichneten Default-Namensgebung 

Positiv sehe ich die Verbesserungen an HM und RFR. Der Rest haette einfach so funktionieren duerfen wie vorher. Kann ich TSCUL_RFR ohne die TSCUL_WS/EM benutzen? Ich sehe hier den Zielkonflikt zwischen Deinem Ansatz (getrennte Empfaenger fuer mehr Sensoren) und meinem Ziel Redundanz im Empfang zu haben. Nach (sehr) kurzem Blick in TSCUL_WS scheint das nicht einfach beides erreichbar zu sein...
Gruss
Peter

Nachtrag: Ein TSCUL_WS konnte ich umbenennen, ebenso ein anderes TSCUL_EM. Beide funktionieren danach weiter und es wird kein "Ersatz" mehr angelegt. Aber das TSCUL_EM_6 ist auch nach wiederholtem Umbennen hartnaeckig.

[noansi]

Hallo Peter,

(Ich hatte probehalber schon vorher versucht einfach das attr IODEV zu loeschen, das hatte aber keinen Effekt)

Das Attribut IODev wird eben ohne die Anpassung an fhem.pl wieder neu gesetzt.

Wird da einfach immer das letzte definierte TSCUL eingetragen?

Ja, und ohne die Änderung an fhem.pl eben auch als Attribut gesetzt (in fhem.pl etwas nach obne scrollen...).

wenn ich ein rename eines Devices mache (z.B. rename TSCUL_EM_6 EM_Pati), dann wird beim naechsten Empfang wieder ein TSCUL_EM_6 angelegt und EM_Pati wird nicht mehr aktualisiert

Und wenn Du es mal in der fhem.cfg umbenennst, statt rename zu nutzen autocreate Leichen löschst und neu startest? (Oder rename, save config und dann Neustart + autocreate Leichen löschen)
Hmm, das scheint mir spontan eher ein Problem mit rename zu sein???

und meinem Ziel Redundanz im Empfang zu haben.

Genau das sollte nach der Änderung an fhem.pl und richtigem Umbenennen + autocreateleichen löschen eigentlich funktionieren.

Mit EM sollte das vorher mit CUL_EM nichts gewesen sein mit Redundanz.

Statt Dich mit dem autocreate abzumühen, wäre es wohl deutlich schneller, direkt händisch die jeweilgen Sensordevices mit Code anzulegen.

Kann ich TSCUL_RFR ohne die TSCUL_WS/EM benutzen?

Nein, not as is.

Gruß, Ansgar.

[noansi]

Hallo Peter,

die Diskussion mit Rudolf und einges Code Studium hat doch ergeben, dass ich das IO-AutoAssign in meinen Sensor-Modulen weglassen kann.
Anbei eine neu Zip mit geänderten Modulen.

Damit wird bei bei via autocreate angelegten Sensoren erst mal kein IODev angelegt. Das Sensordevice sammelt dann erst mal alles was rein kommt (Redundanzempfang).

Wenn man das via IODev aufspalten möchte, dann muss man IODev vie Attribut definieren.

Das hat dann aber zur Folge, dass ein neues device angelegt wird, sobal eine message via einem anderen IDDev empfangen wird. D.h. man muss den Weg dann konsequent für alle IODevices gehen. Praktischerweise sagt der automatisch erzeugte devicename auch, über welches IO empfangen wurde.

autocreate "ignoreTypes" support habe ich auch gleich ergänzt.

Gruß, Ansgar.

@mwllgr: Das Attribut "SlowRfRecToLogLev" ist auch in 00_TSCUL.pm drin.

EDIT: verflixt, Anhang löschen hat funktioniert, aber wieder dranhängen will nicht mehr....