Einbindung SD_WS_33 Sensoren mit Signalduino

Begonnen von JörgK, 28 Februar 2019, 19:11:22

Vorheriges Thema - Nächstes Thema

JörgK

Hallo zusammen,

ich bin neu hier im Forum und beschäftige mich seit einem Monat mit FHEM und anderen Systemen für die Hausautomatisierung.
Für die Erfassung von Temperaturen und der Luftfeuchtigkeit im Haus und zum Experimentieren habe ich mich für 4 recht günstige Funksensoren von Pearl entschieden, da diese laut Google auch vom Signalduino unterstützt werden.
Ich war auch sehr überrascht und erfreut, das die SW des Signalduino und FHEM die Sensoren direkt erkannt und eingebunden haben.
So, und jetzt mein Problem: Ich habe 4 Sensoren gekauft, die aber nur durch drei Kanäle unterscheidbar sind. FHEM generiert dan Einträge für SD_WS_33_TH_1, SD_WS_33_TH_2 und SD_WS_33_TH_3.
D.h. Zwei Sensoren senden immer mit dem Selben Kanal :o

Jetzt geht es ans Eingemachte: Jeder Sender sendet auch eine ID, die bei jedem Batteriewechsel neu generiert wird. Diese wird aber von FHEM nicht ausgewertet. Da habe ich mir das PERL Skript 14_SD_WS.pm angesehen. Und im Abschnitt für das Protokoll 33 folgendes gefunden.

id => <>sub {my (undef,$bitData) = @_; return SD_WS_binaryToNumber($bitData,0,9); },
temp => sub {my (undef,$bitData) = @_; return round(((SD_WS_binaryToNumber($bitData,22,25)*256 +  SD_WS_binaryToNumber($bitData,18,21)*16 + SD_WS_binaryToNumber($bitData,1
hum => sub {my (undef,$bitData) = @_; return (SD_WS_binaryToNumber($bitData,30,33)*16 + SD_WS_binaryToNumber($bitData,26,29));  },
channel => sub {my (undef,$bitData) = @_; return (SD_WS_binaryToNumber($bitData,12,13) );  },
bat => sub {my (undef,$bitData) = @_; return substr($bitData,34,1) eq "0" ? "ok" : "low";},<--># other or modul orginal


Da der Channel im Namen des Sensors in FHEM ist, habe ich zum Channel einfach die id addiert.

id => <>sub {my (undef,$bitData) = @_; return SD_WS_binaryToNumber($bitData,0,9); },
temp => sub {my (undef,$bitData) = @_; return round(((SD_WS_binaryToNumber($bitData,22,25)*256 +  SD_WS_binaryToNumber($bitData,18,21)*16 + SD_WS_binaryToNumber($bitData,1
hum => sub {my (undef,$bitData) = @_; return (SD_WS_binaryToNumber($bitData,30,33)*16 + SD_WS_binaryToNumber($bitData,26,29));  },
channel => sub {my (undef,$bitData) = @_; return (SD_WS_binaryToNumber($bitData,12,13) + SD_WS_binaryToNumber($bitData,0,9) );  },
bat => sub {my (undef,$bitData) = @_; return substr($bitData,34,1) eq "0" ? "ok" : "low";},<--># other or modul orginal


Und siehe da, ich kann alle vier Sensoren eindeutig unterscheiden  8)

Jetzt meine Fragen:
Wäre diese oder eine ähnliche Lösung nicht für alle sinnvoll?
Wie müßte man diese Änderung einspeisen?
Denkbar ist dann auch für mich, dass FHEM eine neue ID erkennt und bei gleichzeitigen Wegfall des alten Sensors die beiden tauscht.

Leider kenne ich mich mit der Syntax von Perl überhaupt nicht aus und kenne auch die internen Abläufe in FHEM nicht. 
Vielleicht können wir hier ja eine Lösung erarbeiten :-)

Gruß Jörg

Harst

Bitte setze einmal für den Signalduino das Attribut longids. Das könnte die Unterscheidung bringen.

Horst

JörgK

Hallo Horst,

den Tipp habe ich mal probiert.
So richtig hat es leider nichts gebracht. Das Verhalten ist so, wie im Original ohne Anpassung der pm Datei.  :'(

Attributes
longids     SD_WS 

Jetzt bekomme ich wieder nur Sensoren 0 - 2

Gruss,
Jörg

Harst

#3
Hallo Jörg,

Setze doch bitte kurzzeitig longids auf 1, damit klar ist, ob der Wert sd_ws richtig ist.

Horst

Edit: blöde Autokorrektur

elektron-bbs

longids:
# Keine langen IDs verwenden (Default Einstellung):
attr sduino longids 0
# Immer lange IDs verwenden:
attr sduino longids 1
# Verwende lange IDs für SD_WS07 Devices.
# Device Namen sehen z.B. so aus: SD_WS07_TH_3.
attr sduino longids SD_WS07

Du müsstest also z.B. folgendes verwenden:

attr sduino longids SD_WS_33_TH
Intel(R) Atom(TM) CPU N270 mit 2 SIGNALduino nanoCC1101 + ESPEasy 2x serial server SIGNALduino nanoCC1101, Raspberry Pi 2 mit 2 CUL Stackable CC1101, Raspberry Pi 3 mit SIGNALduino radino + nano328 + 2 x SIGNAL-ESP CC1101 + LaCrosseGateway

JörgK

Ja super,

mit SD_WS_33_TH hat er es gefressen.

Jetzt stellt FHEM die ID an den Namen an. "SD_WS_33_TH_0_215"
So kann ich erstmal weitermachen.

Danke erstmal.

Jetzt ist da noch die unschöne Tatsache, dass nach einem Batteriewechsel ein neuer Name generiert wird.
Kann man das evtl. automatisch über Alias lösen?

  • Skript starten bei Generierung eines neuen SD_WS_33_TH Device
  • Schauen welcher Sensor nicht mehr sendet.
  • Alias neu zuweisen
  • Alte Verlaufshistorie auf neues Device kopieren (sichern)?
  • Altes Device löschen.

Ich wüßte jetzt nicht, ob es in FHEM eine Programmierschnittstelle für sowas gibt oder ob man direkt in den Systemdateien rumwerkeln muss?

Es gibt immer etwas zu Verbesser  8)

Gruß,
Jörg