Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

putzvarruckt · 02 September 2019, 23:14:35

Hallo zusammen,

ich such nun schon seit einiger Zeit und finde keine Lösung:
Meine Tchibo Wetterstation wird als CUL_TCM97001 erkannt. Funktioniert soweit.
Aber wenn ich jetzt die Batterien wechsle, ändert der Sender ja seinen Rolling-Code und mein FHEM legt einen neuen Sensor an!
Alle Bezüge die ich auf den alten angelegt habe funktionieren nicht mehr (Charts, notify, ...).
Als Workaround ändere ich dann immer die DEF des Sensors ab sodass alles wieder zusammen passt, aber das kann nicht der Sinn sein...

Gibt es da eine Möglichkeit das zu umgehen?
Ich verwende "V 3.3.2.1-rc8 SIGNALduino cc1101 - compiled at Jan 10 2019 20:10:21" über ESP01 und "V 3.3.2.1-rc8 SIGNALduino - compiled at Feb 10 2019 13:22:11" direkt an der RS232 des Raspi weil damit die anderen Sensoren auch einwandfrei funktionieren (Typ SD_WS).

Mit neueren Versionen der SIGNALduino hab ich dann viel schlechteren Empfang...

Hat da jemand eine Idee?

Danke

Friedrich

cs-online · 03 September 2019, 09:25:07

Ja, das Problem habe ich m it den Eurochrons auch jedes mal, zumal die irgendwie auch häufiger der Schwerkraft folgend sich dann in mehrere Teile zerlegen und dann nach Batterie einlegen natürlich wieder eine andere ID bekommen. Cool wäre es, wenn man das so wie beim Lacrosse-GW machen könnte, da gibt es ein Set replaceBatteryForSeconds, wenn innerhalb der Zeit eine ID gefunden wird, die noch unbekannt ist, dann wird der alte mit der neuen ID verknüpft...

Sidey · 03 September 2019, 09:37:01

Hi,

Da ist wenig was ich aus dem SIGNALduino Modul anbieten kann.

Es gibt das Attribut longids im SIGNALduino.
Dieses könnte das CUL_TCM97001 Modul auswerten um zu erkennen ob die Zufalls ID mit in der Definition berücksichtigt werden sollte.

elektron-bbs · 03 September 2019, 17:27:15

CUL_TCM97001 nutzt IMHO von Hause aus immer longids:

my $enableLongIDs = TRUE; # Disable short ID support, enable longIDs
my $longids = AttrVal($iodev,'longids',1);

putzvarruckt · 04 September 2019, 14:03:37

Heißt das dass eventuell das Problem mit den short IDs nicht auftritt?

Friedrich

elektron-bbs · 04 September 2019, 17:34:03

Das könnte sein. Wenn die Sensoren einen Umschalter für "Kanal" haben und im TCM-Modul dieser unterstützt wird, dann werden diese statt mit der longid mit dem fest eingestellten Kanal definiert. Dieser ändert sich ja dann bei einem Batteriewechsel nicht.

Sidey · 04 September 2019, 21:28:36

Hi,

Prinzipiell ja.
Leider dann aber doch nicht wirklich. Zumindest nicht aus meiner Erinnerung.

Der Modul Author hat zwar vorgesehen, dass man das Modul "umstellen kann" auf ShortID Support.
Aber dazu müsstest Du im Quelltext eine Zeile verändern:

Code Auswählen

my $enableLongIDs = TRUE; # Disable short ID support, enablelongIDs

Diese Änderung überschreibst Du mit dem Nächsten Update gleich wieder, oder Du nimmst es aus dem Update raus.

Wenn es also nicht klappt, solltest Du dein Problem an den Modul Author herantragen, damit er diese Konfiguration änderbar gestaltet.
Grüße Sidey

HomeAuto_User · 04 September 2019, 21:57:37

Zitat von: Sidey am 04 September 2019, 21:28:36
Hi,

Prinzipiell ja.
Leider dann aber doch nicht wirklich. Zumindest nicht aus meiner Erinnerung.

Der Modul Author hat zwar vorgesehen, dass man das Modul "umstellen kann" auf ShortID Support.
Aber dazu müsstest Du im Quelltext eine Zeile verändern:

Code Auswählen Erweitern
my $enableLongIDs = TRUE; # Disable short ID support, enablelongIDs

Diese Änderung überschreibst Du mit dem Nächsten Update gleich wieder, oder Du nimmst es aus dem Update raus.

Wenn es also nicht klappt, solltest Du dein Problem an den Modul Author herantragen, damit er diese Konfiguration änderbar gestaltet.
Grüße Sidey

Das wäre mal wieder nen Punkt um den Maintainer zu "zirpen"

Ralf9 · 05 September 2019, 12:17:44

Zitatmy $enableLongIDs = TRUE; # Disable short ID support, enablelongIDs
Wenn es also nicht klappt, solltest Du dein Problem an den Modul Author herantragen, damit er diese Konfiguration änderbar gestaltet.

Es änderbar machen ist wahrscheinlich nicht so einfach möglich.
Eine Möglichkeit für den Signalduino wäre, ein zusätzliches Attribut (z.B. CUL_TCM97001_activate_shortID) in der 00_SIGNALduino.pm.
Dieses Attribut müsste dann in dem CUL_TCM97001 Modul abgefragt werden.

Oder hat jemand eine bessere Idee wie man dies konfigurierbar machen könnte?

Gruß Ralf

elektron-bbs · 05 September 2019, 17:07:44

Wenn man sowieso die CUL_TCM97001 bearbeiten müsste, kann man dort auch gleich longids richtig implementieren, so das es dort schaltbar ist.

Sidey · 05 September 2019, 18:36:35

Ich hatte dazu schon einen patch erstellt.
Das SIGNALduino Modul stellt bereits ein Attribut zur Verfügung um zu bestimmen ob die Zufallscodes berücksichtigen werden sollen oder ob nicht.

Der wurde damals leider nicht 1:1 umgesetzt und diese globale Variable steuert letztlich für das komplette Modul ob der Patch von damals angewendet wird oder nicht.

Leider finde ich den Beitrag von damals nicht mehr

Grüße Sidey

Ralf9 · 05 September 2019, 19:01:05

ZitatWenn man sowieso die CUL_TCM97001 bearbeiten müsste, kann man dort auch gleich longids richtig implementieren, so das es dort schaltbar ist.

Dies sollte aber kompatiblel zur jetztigen Version des CUL_TCM97001 Moduls sein.
Bei nicht aktiven longids Attribut sollte weiterhin der short ID support im CUL_TCM97001 disabled sein.
Sonst werden bei sehr vielen usern nach einem update die CUL_TCM97001 Sensoren nicht mehr funktionieren oder mit der shortId neu angelegt.

Gruß Ralf

Ralf9 · 06 September 2019, 10:50:40

ZitatMeine Tchibo Wetterstation wird als CUL_TCM97001 erkannt.

Kannst Du bitte mal ein List davon posten?

ZitatMit neueren Versionen der SIGNALduino hab ich dann viel schlechteren Empfang...

Wie ist Deine aktuelle Version (Internals versionmodul)

Mit welcher Version ist der Empfang schlechter und welche Sensoren sind davon betroffen?

Gruß Ralf

schwatter · 16 September 2019, 13:30:20

Hallo,

habe erst frisch gewechselt von a-culfw auf SIGNALduino. Die Fülle an Informationen ist sehr groß.
Ein Thread springt in den nächsten und nicht alle Links sind 100% aktuell.
Um da einen Leitfaden für mich zu finden, versuche ich die verschiedenen Repos zu durchschauen.

Im ersten Thread steht, das RFFHEM voll auf die Firmware V 3.3.0 (SIGNALduino - compiled at Sep 18 2016 00:28:28) setzt,
und darauf aufbaut. Allerdings ist der Ralf9 ja auch mit im Boot und strickt an seinem Fork von SIGNALduino.

Bis heute Morgen habe ich Ralf9 seine Firmware genutzt, bei der ich keine negativen Aspekte mit meinem kleinen Fuhrpark von
3 Devices feststellen konnte. Aus Neugier habe ich eben auf RFFHEM 3.4 geupdatet.

Code Auswählen

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Welche Kombi wird denn empfohlen? Ausprobieren angesagt?

putzvarruckt · 16 September 2019, 18:48:54

Zitat von: Ralf9 am 06 September 2019, 10:50:40
Kannst Du bitte mal ein List davon posten?
Wie ist Deine aktuelle Version (Internals versionmodul)

Mit welcher Version ist der Empfang schlechter und welche Sensoren sind davon betroffen?

Gruß Ralf

Ich hab "V 3.3.2.1-rc8 SIGNALduino" installiert.
Damals als ich diese im Feb. installiert habe hat die neueste (iwas mit 3.3.3xxx keinen meiner Sensoren mehr erkannt.
Ich hab einen CUL_TMC9001 und einige die als SD_WS erkannt werden. Sind
tfa-dostmann TFA Digitale 30.5045.54 thermo-hygrometer und kompatible. TFA 30.3054

Bin gerade unterwegs und komme nicht an das System für ein Listing, was würdest du brauchen?

Friedrich