Signalduino Entwicklung

[trebron106]

Hallo Sven,

einfach wie im SIGNALduino WIKI beschrieben ein Update der SIGNALDuino Version machen und danach über Fhem oder manuell flashen.

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt
set sduino flash

Die Firmware befindet sich im Verzeichnis FHEM/firmware
Ich selber benutze einen Arduino Nano mit der aktuellen Version 3.2.0-b12



Hallo Ralf,

habe in den Sketch zum Test die send_raw BCD Routine eingebaut und meine Daten nach BCD konvertiert. Das senden und wandeln der BCD Daten als RAW klappt einwandfrei. Es wäre vielleicht ganz gut wenn die Wandlung des Rawdaten Strings in einer späteren Version in Fhem unter Perl erolgen würde, weil ASCII Daten leichter lesbar sind.

Gruß
Klaus

[Ralf9]

habe in den Sketch zum Test die send_raw BCD Routine eingebaut und meine Daten nach BCD konvertiert. Das senden und wandeln der BCD Daten als RAW klappt einwandfrei. Es wäre vielleicht ganz gut wenn die Wandlung des Rawdaten Strings in einer späteren Version in Fhem unter Perl erolgen würde, weil ASCII Daten leichter lesbar sind.

Ja, dies ist für das Release 3.3 vorgesehen.

Gruß Ralf

[hoods]

Hallo Klaus,

ich wollte deine Anpassungen an dem Sketch (RF_Receiver.ino) testen und so auch meine Rolladen damit steuern (und mich mit Signaldino vertraut machen ....).

Im firmware Verzeichnis liegt ja nur das fertig hex File. Und wenn ich es recht verstehe sind deine Anpassungen noch nicht in die dev Version aufgenommen, sodaß ich einfach das aktuellste hex File laden könnte, oder irre ich mich?

Gruß Sven

[Sidey]

ich wollte deine Anpassungen an dem Sketch (RF_Receiver.ino) testen und so auch meine Rolladen damit steuern (und mich mit Signaldino vertraut machen ....).

In der aktuellen Firmware sind die Anpassungen, welche zum Senden von Signalen >255 enthalten.
Ich habe dazu einige der Änderungen von trebron106 übernommen, allerdings nicht alle.

Damit sollte man Fernotron Rolläden schalten können. Empfangen geht leider im Moment nicht.

Grüße Sidey

[hoods]

Super, erste Versuche sind erfolgreich.

Vielen Dank!

Gruß Sven

[Sidey]

Hi Ralf,

ich habe mir Gedanken zu dem SD_WS Modul und Komplexität gemacht.

Komplexität ist unterschiedlich je nach Standpunkt. Ich habe es bislang aus der Sicht Pflege und Anpassungen gesehen. Da sind so lange if / else Schlangen halt etwas unübersichlicht.

Für den Ersteller, der nur schnell seinen Sensor einbauen will ist es natürlich erst mal einfacher er muss sich im nichts kümmern außer am Ende einen if / else Schalter einbauen.
Wenn man aber mal mehrere Sensoren in einem Protokoll hat, wird es vielleicht schon etwas aufwendiger.

Was meine Perl Kenntnisse angeht, so gut sind die nicht. Ich hänge auch ständig an irgendwelchen blöden Syntax Fehlern oder Dereferenzierungen...

Ich habe versucht, mich mehr in die Situation des Erstellen eines neuen Sensors begeben.
Dabei ist mir aufgefallen, derjenige, der einen Sensor in Fhem integrieren will, möchte sich vermutlich möglichst wenig mit Programmieren und auch eher weniger mit Eigenheiten von Modulen beschäftigen.

Also bin ich zu dem Schluss gekommen, dass es möglich sein soll, dass man einen Sensor implementiert, in dem man eine art Konfiguration hinterlegt.

In der Regel ist die Frage, in welchem Bit steht die Temperatur und wie muss man diesen Wert umrechnen um ihn darstellen zu können.
Dabei kam mir die Idee, wieso das Konzept nicht aufnehmen, welches ich schon im SIGNALduino Modul eingebaut habe. Die %ProtocolListSIGNALduino ist eigentlich nichts anderes. Es ist eine Konfigurationsmöglichkeit um Signale zu demodulieren. Je nach Protokoll, dauert es manchmal nur ein paar Minuten und die Definition ist ergänzt.

Also habe ich das Konzept aufgegriffen und mal in Richtung Sensoren transferiert.
Da ich Beispiele mag, kommt das nun hier:

Code Auswählen Erweitern


my %Sensordevices  = (
  "37"    =>
        {
            model => 'SD_WS37_TH',
            type => 'Besser 7009994',
predec => sub { return shift }, # Hier könnte eine Funktion rein, die vor dem Decodieren etwas mit den Daten macht
data =>
{
'id' => sub { my $bitdata=shift; return SD_WS_binaryToNumber($bitdata,0,7); },
'bat' => sub { my $bitdata=shift; return SD_WS_binaryToNumber($bitdata,8,9) eq "1" ? "ok" : "low"; },
'channel' => sub { my $bitdata=shift; return SD_WS_binaryToNumber($bitdata,11,12); },
'temp' => sub { my $bitdata=shift; return (SD_WS_binaryToNumber($bitdata,12,22) - 609.93) / 9.014; },
'humidity => sub { my $bitdata=shift; return SD_WS_binaryToNumber($bitdata,25,31); },
},

chkcrc => sub{return 1;}, # Hier könnte eine CRC Prüfung stattfinden
valid => sub{my $temp=shift;my $hum=shift; return (80<$temp>-40 && 10<$hum>99); },# Festsellen, ob die Werte in einem validen Bereich liegen. Dazu kann man auch eine Standardfunktion referenzieruen
      }
   },
);


So könnte eine solche Sensor Definition aussehen, auch wenn ich noch nicht alles durchdacht habe.

Den Abschnitt Sensorwerte (id, temp, ...) auslesen könnte man wohl noch vereinfachen.

Code Auswählen Erweitern


'id' => (0,7)  # Bit 0-7 entsprechen der id

Und für Standardfälle wie temp und hum Prüfung, lassen sich auch Standardfunktionen definieren


Der Teil SD_WS_Parse könnte durch diese Aufteilung "konstant" bleiben.
In etwa so:

Code Auswählen Erweitern


sub SD_WS_Parse($$)
{
my ($iohash, $msg) = @_;
my $name = $iohash->{NAME};
my ($protocol,$rawData) = split("#",$msg);
$protocol=~ s/^[WP](\d+)/$1/; # extract protocol

my $hlen = length($rawData);
my $blen = $hlen * 4;
my $bitData = unpack("B$blen", pack("H$hlen", $rawData));


#Hier werden die in der Konfiguration definierten Funktionen aufgerufen.
$bitData =$Sensordevices{$protocol}{predec}->($bitdata};
my $id = printf('%02X',$Sensordevices{$protocol}{data}{id}->($bitdata});
my $bat =$Sensordevices{$protocol}{data}{bat}->($bitdata};
my $channel =$Sensordevices{$protocol}{data}{channel}->($bitdata};
my $temp =sprintf("%.1f",$Sensordevices{$protocol}{data}{temp}->($bitdata});
my $hum =$Sensordevices{$protocol}{data}{humidity}->($bitdata};

if ( $Sensordevices{$protocol}{chkcrc}->($bitData) && $Sensordevices{$protocol}{valid}->($temp,$hum,$bat,$channel,$humidity) )
{
my $SensorTyp=$Sensordevices{$protocol}{type};

Log3 $iohash, 4, "$name decoded protocolid: $protocol ($SensorTyp) sensor id=$id, channel=$channel,  temp=$temp, hum=$hum";
}
        ....
}




Ich hab den Code nun nicht wirklich ausprobiert und es sind bestimmt Syntaxfehler enthalten.
Aus meiner Sicht, wäre das für das Einbinden weiterer Sensoren erst mal weniger komplex, da man nur die "Konfiguration" ergänzen muss.
Initial muss man sich das ganze natürlich einmal hinbauen, was ich nun aber in 30 Minuten auch schon mal grob erledigt habe. Vielleicht kriegen wir es ja auch noch mal hin, dass man die Konfiguration irgendwie über das UI anpassen kann.

Nunja, das sind jetzt erst mal meine Gedanken zum dem Thema. Fertig ist es nicht,
Offen ist in meinem Beispiel noch der Fall, mehrere Sensoren in einem Protokoll
oder den Abschnitt "data" könnte  man eventuell auch eine Schleife laufen lassen. so in etwa:

Code Auswählen Erweitern


my %sensordata ;
foreach $key keys %{$Sensordevices{$protocol}{data}}
{
      $sensordata{$key} =$Sensordevices{$protocol}{data}{$key}
}


und dann später

Code Auswählen Erweitern


my %sensordata ;
foreach $val keys %sensordata
{
readingsBulkUpdate($hash, "$val", $sensordata{$val}) ;
        ### Stateformat anpassen
}


Damit wäre man im Code schon mal nicht unbedingt auf readings festgelegt und kann leicht neue dazu nehmen.


So in etwa könnte man das Einbinden von Sensoren auf eine neue "Stufe" bringen.
Für Autocreate müssten wir uns halt noch mal was überlegen, da bin ich jetzt unsicher wie man da am besten andockt.

Grüße Sidey

[waschbaerbauch]

Ich schon wieder

Eigentlich sollte es doch möglich sein diese Conrad Profi Wetterstation slim mit dem SIGNALduino abzufangen. Also die Basis nicht, aber die externen Sensoren? Das sind in dem Bundle ja immerhin noch der Regensensor, Temperatur/Luftfeuchte Sensor und der Windgeschwindigkeits- / -richtungs Sensor.

Die Verbindung via USB mit der Basis wurde bei diesem optisch identischem Modell eingespart im Gegensatz zur Conrad Variante inkl. Software.
Man müsste hier also erstmal teuer die Variante mit Software erstehen, damit man auf eine andere Software schwenken kann..

Unter http://te923.fukz.org/ gibt es ggf. sogar Hinweise wie man an das Protokoll der Sensoren kommt.

Die technischen Daten lt. BDA

Code Auswählen Erweitern

19. Technische Daten
a) Wetterstation
Temperatursensor:
Messbereich: -5 °C bis +50 °C
Auflösung: 0,1 °C
Genauigkeit: ±1 °C (im Bereich von 0 °C bis +40 °C)
Messzyklus: 10 s

Luftfeuchtesensor:
Messbereich: 1% to 99% relative Luftfeuchte
Auflösung: 1%
Genauigkeit: ±7% (im Bereich von 25% bis 80%)
Messzyklus: 10 s

Luftdrucksensor:
Messbereich: 500 hPa bis 1100 hPa
Auflösung: 0,1 hPa
Genauigkeit: ±5 hPa
Höhenmessbereich: -200 m bis +5000 m

Regensensor
Messbereich: 0 bis 1999,9 mm
Sendefrequenz: 433 MHz
Übertragungszyklus: ca. 183 s

Temperatur-/Luftfeuchtesensor
Temperatursensor:
Messbereich: -20 °C bis +60 °C
Auflösung: 0,1 °C
Genauigkeit: ±1 °C (im Bereich von 0 °C bis +40 °C)
Luftfeuchtesensor:
Messbereich: 1% to 99% relative Luftfeuchte
Genauigkeit: ±7% (im Bereich von 25% bis 80%)
Sendefrequenz: 433 MHz
Messintervall: ca. 47 s

Windsensor
Windrichtungssensor:
Genauigkeit: ±11,25°
Auflösung: 22,5°
Geschwindigkeitssensor:
Messbereich: 0 bis 199,9 km/h
Genauigkeit: ±3 km/h + 5%
Sendefrequenz: 433 MHz
Übertragungszyklus: ca. 33 Sekunden

Hier Im Anhang ein kleiner Auszug des Logs (Verbose4)


Ist hier was zu machen?

[Ralf9]

Ich schon wieder

Eigentlich sollte es doch möglich sein diese Conrad Profi Wetterstation slim mit dem SIGNALduino abzufangen. Also die Basis nicht, aber die externen Sensoren? Das sind in dem Bundle ja immerhin noch der Regensensor, Temperatur/Luftfeuchte Sensor und der Windgeschwindigkeits- / -richtungs Sensor.
Hier Im Anhang ein kleiner Auszug des Logs (Verbose4)

Ist hier was zu machen?

Ist dies der dazugehörende Temperatursensor:

Code Auswählen Erweitern

2016.02.07 23:36:12 4: SIGduino: Found manchester Protocol id 12 clock 451 -> Hideki protocol
2016.02.07 23:36:12 4: SIGduino: hideki protocol converted to hex: 75E7BA8ADE40D051C86900 with 95 bits, messagestart 1
2016.02.07 23:36:12 4: Hideki_Parse SIGduino incomming P12#75E7BA8ADE40D051C86900
2016.02.07 23:36:12 4: Hideki_Parse SensorTyp = 30 decodedString = 7529ce9e62c070f358bb00
2016.02.07 23:36:12 4: SIGduino decoded Hideki protocol model=Hideki_30, sensor id=29, channel=1, temp=6.2, humidity=70, bat=ok

Sind der Regen- und Windsensor im selben Raum wie der Signalduino?

Gruß Ralf

[waschbaerbauch]

Moin Ralf,

der SIGNALduino ist im selben Raum wie die Basisstation. Die Signale kommen zumindest bei der Basisstation an.
Der Temperatur/Luftfeuchte Sensor steht am Badfenster, der Regenmesser ist ebenso wie der Windmesser auf dem Hof montiert.

Nach dem Arztbesuch könnte ich 'auf die Schnelle' zumindest den Temperatur/Luftfeuchte Sensor ins Wohnzimmer holen wo sich der SIGNALduino befindet.

Gruß
Mario

[Ralf9]

der SIGNALduino ist im selben Raum wie die Basisstation. Die Signale kommen zumindest bei der Basisstation an.
Der Temperatur/Luftfeuchte Sensor steht am Badfenster, der Regenmesser ist ebenso wie der Windmesser auf dem Hof montiert.

Wenn Du am Signalduino keine gute Antenne hast, dann wird die Basisstation einen besseren Empfang haben.
Hilfreich wäre zu wissen, ob die Sensoren das Hideki Protokoll (MC-Nachrichten) verwenden oder ob es MU-Nachrichten sind.

Gruß Ralf

[Sidey]

Laut verlinkten Seite nutzen diese Sensoren das Hideki Protokoll...

Grüße Sidey

[Ralf9]

Beim Hideki Protokoll müssten dann bei brauchbarem Empfang bei der folgenden Zeile

Code Auswählen Erweitern

Hideki_Parse SensorTyp = 30 decodedString = 7529ce9e62c070f358bb00
beim SensorTyp außer 30 noch andere Werte, wie z.B. 12 und 14 auftauchen.

Gruß Ralf

[Ralf9]

Nunja, das sind jetzt erst mal meine Gedanken zum dem Thema. Fertig ist es nicht,
Offen ist in meinem Beispiel noch der Fall, mehrere Sensoren in einem Protokoll

Hallo Sidey,

bei der Temperatur müssten auch noch negative Temperaturen berücksichtigt werden können

Code Auswählen Erweitern

      $temp    = (hex($a[4].$a[5].$a[6])) & 0x7FFF; 
      my $negative    = (hex($a[4])) & 0x8;

      if ($negative == 0x8) {
        $temp = (~$temp & 0x07FF) + 1;
        $temp = -$temp;
      }
      $temp = $temp / 10;


oder:

Code Auswählen Erweitern

    if ($temp >= 3840) {
      $temp -= 4095;
    } 
    $temp /= 10;

Es kann wie z.B. beim Modell "KW9010" auch etwas komplexer werden:

Code Auswählen Erweitern

        foreach $x (@a) {
           my $bin3=sprintf("%024b",hex($x));
           $bitReverse = $bitReverse . substr(reverse($bin3),0,4);
        }
        my $hexReverse = unpack("H*", pack ("B*", $bitReverse));

        #Split reversed a again
        my @aReverse = split("", $hexReverse);

        if (hex($aReverse[5]) > 3) {
           # negative temp
           $temp = ((hex($aReverse[3]) + hex($aReverse[4]) * 16 + hex($aReverse[5]) * 256));
           $temp = (~$temp & 0x03FF) + 1;
           $temp = -$temp/10;
        } else {
           # positive temp
           $temp = (hex($aReverse[3]) + hex($aReverse[4]) * 16 + hex($aReverse[5]) * 256)/10;
        }


Bei mehreren Sensoren in einem Protokoll kann als Unterscheidungskriterium auch Hum = 0 sein oder die Prüfsumme


Gruß Ralf

[waschbaerbauch]

Sitze gerade vor der Praxis im eigenen Wartezimmer (im Auto). Bin wohl ansteckend..

Hoffe gegen Mittag daheim zu sein und mit einem 'Batteriewechsel' Signale aus einem passenden Zeitabschnitt mitschneiden zu können.

Gruß
Mario

[waschbaerbauch]

Nun ging doch alles schneller als erwartet.

Dies müsste nun der Temperatur/Luftfeuchte Sensor von der Conrad Profi slim sein. Ich hatte mal die Batterie gewechselt und ihn eine Weile in der Hand gehalten, daher die gestiegene Temperatur.

Code Auswählen Erweitern

2016.02.08 10:04:41 4: SIGNALduino/msg READ: MC;LL=-1025;LH=933;SL=-531;SH=441;D=AE2C174A4433E85094374600;C=457;
2016.02.08 10:04:41 4: SIGduino: hideki protocol converted to hex: 751ABA4AC2BE2852EC3100 with 96 bits, messagestart 0
2016.02.08 10:04:41 4: Hideki_Parse SIGduino incomming P12#751ABA4AC2BE2852EC3100
2016.02.08 10:04:41 4: Hideki_Parse SensorTyp = 30 decodedString = 752ecede46c278f6345300
2016.02.08 10:04:41 4: SIGduino decoded Hideki protocol model=Hideki_30, sensor id=2e, channel=1, temp=24.6, humidity=78, bat=ok


Ist es nahe liegend, das alle anderen Sensoren auch dann Einträge in dieser Art erzeugen?