Signalduino Entwicklung

[waschbaerbauch]

Ok, es gibt 2 Versionen? Egal..

Code Auswählen Erweitern

2016.02.08 19:25:47 4: SIGduino/msg READ: MC;LL=-1030;LH=923;SL=-543;SH=432;D=AE00888BA07001107A0200;C=451;
2016.02.08 19:25:47 4: SIGduino: Found manchester Protocol id 10 clock 451 -> OSV2o3
2016.02.08 19:25:47 4: SIGduino: Found manchester Protocol id 12 clock 451 -> Hideki protocol
2016.02.08 19:25:47 4: SIGduino: hideki protocol converted to hex: 758044BAE00022BC4000 with 88 bits, messagestart 0
2016.02.08 19:25:47 4: Hideki_Parse SIGduino incomming P12#758044BAE00022BC4000
2016.02.08 19:25:47 4: Hideki_Parse SensorTyp = 14 decodedString = 7580ccce200066c4c000
2016.02.08 19:25:47 4: SIGduino decoded Hideki protocol model=Hideki_14, sensor id=80, channel=4, temp=0, humidity=0, bat=ok, rain=22.4


Nachdem ich das getan hab wird der Regenmesser empfangen.

PS: mir war es noch gar nicht aufgefallen, das hier ein anderer Link als im Wiki steht.

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Hab ich wohl nicht geblickt, sorry

[Sidey]

Ok, es gibt 2 Versionen? Egal..

Kein Problem,  es gibt die Version 3.1, welche mit Fhem verteilt wird.
Die ist soweit recht stabil.

Die Version 3.2 ist noch in Entwicklung. Da sind viele Verbesserungen eingeflossen.
Da beim Entwickeln immer mal was schief läuft, wird diese Version erst mit Fhem verteilt, wenn wir mit der Entwicklung fertig sind. Danach kommt dann Version 3.3...

Grüße Sidey

[waschbaerbauch]

Ja ich fühl mich nur blöd wenn ich euch, so hilfsbereit wie ihr seid, noch mehr Arbeit mache

Anbei das Logfile vom EVAL System. Hier taucht nun nichts mehr wegen dem Windsensor auf oder ich hab Tomaten auf den Augen.

Code Auswählen Erweitern

set disableMessagetype unsyncedMU

ist aktiv!

Gruß
Mario

[pejonp]

Hallo Sidey,

ich habe heute wieder mal ein Update gemacht aber die Probleme mit der schlechten Erkennung des Hideki-Protokolls hat sich nicht geändert (http://forum.fhem.de/index.php/topic,38831.msg400499.html#msg400499).
Ich habe im  00_SIGNALduino.pm (95487 2016-03-02 12:24:00 v3.2-dev ) auch schon die 
clockrange        => [420,510]  angepaßt. Wird aber nicht besser.

Code Auswählen Erweitern


2016.02.08 21:10:22 5: sduino: converted Data to (s0500D700F800)
2016.02.08 21:10:22 4: sduino: Dropped (s0500D700F800) due to short time or equal msg
2016.02.08 21:10:22 4: sduino/msg READ: MU;P0=514;P1=-2057;P2=-3768;D=010101010102020102010202020101010101010101020202020;CP=0;
2016.02.08 21:10:22 5: sduino: applying filterfunc SIGNALduino_filterSign
2016.02.08 21:10:26 4: sduino/msg READ: MC;LL=-962;LH=1001;SL=-474;SH=502;D=7A174A6CC7EB31148D2700;C=500;
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 10 clock 500 -> OSV2o3
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 12 clock 500 -> Hideki protocol
2016.02.08 21:10:26 4: sduino/msg READ: MC;LL=-967;LH=987;SL=-481;SH=496;D=AE7A174A2CC7EB31148F0900;C=494;
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 10 clock 494 -> OSV2o3
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 12 clock 494 -> Hideki protocol
2016.02.08 21:10:26 4: sduino: hideki protocol converted to hex: 752FBA8A33BF3351F14800 with 96 bits, messagestart 0
2016.02.08 21:10:26 5: sduino: converted Data to (P12#752FBA8A33BF3351F14800)
2016.02.08 21:10:26 5: sduino dispatch P12#752FBA8A33BF3351F14800
2016.02.08 21:10:26 4: Hideki_Parse sduino incomming P12#752FBA8A33BF3351F14800
2016.02.08 21:10:26 4: Hideki_Parse SensorTyp = 30 decodedString = 7571ce9e55c155f313d800
2016.02.08 21:10:26 4: sduino using longid: 1 model: Hideki_30
2016.02.08 21:10:26 4: sduino decoded Hideki protocol model=Hideki_30, sensor id=71, channel=3, temp=15.5, humidity=55, bat=ok, rain=0
2016.02.08 21:10:26 5: deviceCode: Hideki_30_71.3
2016.02.08 21:10:26 4: sduino/msg READ: MC;LL=-980;LH=979;SL=-485;SH=487;D=AE7A174A4CC7EB31148C3D00;C=488;
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 10 clock 488 -> OSV2o3
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 12 clock 488 -> Hideki protocol
2016.02.08 21:10:26 4: sduino: hideki protocol converted to hex: 752FBA4A33BF3351315E00 with 96 bits, messagestart 0
2016.02.08 21:10:26 5: sduino: converted Data to (P12#752FBA4A33BF3351315E00)
2016.02.08 21:10:26 5: sduino dispatch P12#752FBA4A33BF3351315E00
2016.02.08 21:10:26 4: Hideki_Parse sduino incomming P12#752FBA4A33BF3351315E00
2016.02.08 21:10:26 4: Hideki_Parse SensorTyp = 30 decodedString = 7571cede55c155f353e200
2016.02.08 21:10:26 4: sduino using longid: 1 model: Hideki_30
2016.02.08 21:10:26 4: sduino decoded Hideki protocol model=Hideki_30, sensor id=71, channel=3, temp=15.5, humidity=55, bat=ok, rain=0
2016.02.08 21:10:26 5: deviceCode: Hideki_30_71.3
2016.02.08 21:10:26 4: sduino/msg READ: MC;LL=-980;LH=979;SL=-485;SH=487;D=AE7A174A4CC7EB31148C3D00;C=488;
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 10 clock 488 -> OSV2o3
2016.02.08 21:10:26 4: sduino: Found manchester Protocol id 12 clock 488 -> Hideki protocol
2016.02.08 21:10:26 4: sduino: hideki protocol converted to hex: 752FBA4A33BF3351315E00 with 96 bits, messagestart 0
2016.02.08 21:10:26 5: sduino: converted Data to (P12#752FBA4A33BF3351315E00)
2016.02.08 21:10:26 4: sduino: Dropped (P12#752FBA4A33BF3351315E00) due to short time or equal msg



Wo kan ich noch etwas anpassen ? Danke.

Jörg
PS: Ich habe eigentlich an meinem Versuchsaufbau nichts geändert. Ich habe einmal die Antenne etwas verlegt, jetzt kommen bessere Ergebnisse.

[Ralf9]

Anbei das Logfile vom EVAL System. Hier taucht nun nichts mehr wegen dem Windsensor auf oder ich hab Tomaten auf den Augen.

Code Auswählen Erweitern

set disableMessagetype unsyncedMU

ist aktiv!

Können dies evtl fehlerhaft empfangene Windsensor Nachrichten sein?

Code Auswählen Erweitern

Hideki_Parse SensorTyp = 0 decodedString = 7508030000004bd400
SIGduino crc failed

@Sidey
Könnte es auch denkbar sein, daß der Windsensor ein anderes Protokoll sendet? z.B. MU-Nachrichten?

Gruß Ralf

[Sidey]

@Sidey
Könnte es auch denkbar sein, daß der Windsensor ein anderes Protokoll sendet? z.B. MU-Nachrichten?

Hallo Ralf,

ausschließen kann ich es nicht, aber zum einen halte ich das für unwahrscheinlich, dass jemand unterschiedliche Protokolle verwendet und zum anderen passt das nicht zu den Recherchen in der verlinkten Seite.

Eher glaube ich, dass was mit der Auswertung der Daten nicht stimmt.
Also, z.B. ist die Nachricht länger oder kürzer und wird deshalb nicht erkannt.


Grüße Sidey

[Sidey]

Mir ist ja nur das aufgefallen.

Code Auswählen Erweitern


2016.01.27 16:02:36 4: sduinousb/msg READ: MC;LL=-952;LH=1005;SL=-481;SH=502;D=7A174A61B7EBB1147A2E00;C=502;
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 10 clock 502 -> OSV2o3
2016.01.27 16:02:36 4: sduinousb Found manchester Protocol id 12 clock 502 -> Hideki protocol


Hmm, das ist seltsam finde ich. Es wird das Protokoll erkannt, danach kommen aber keinerlei Meldungen mehr die irgend einen Rückschluss auf das was da passiert zulassen.
Ich schau mal, ob wir da in den letzten 3 Wochen etwas verändert haben.

Grüße Sidey

[pejonp]

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

Hallo Sidey, Hallo Ralf,

vielleicht könnte man die Beschreibung der Wetter-Protokolle/Sensoren so ähnlich machen wir hier im Modul 21_VBUSDEV.pm. Was ihr ja schon so beschrieben habt.

Code Auswählen Erweitern


my %VBUS_devices = (
"7751" => {"name" => "DiemasolC", "cmd" => "0100", "fields" => [
{ "offset" =>  0,"name" => "temperature_T01","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  2,"name" => "temperature_T02","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  4,"name" => "temperature_T03","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  6,"name" => "temperature_T04","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" =>  8,"name" => "temperature_T05","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 10,"name" => "temperature_T06","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 12,"name" => "temperature_T07","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 14,"name" => "temperature_T08","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 16,"name" => "temperature_T09","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 18,"name" => "temperature_T10","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 20,"name" => "temperature_T11","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
  { "offset" => 22,"name" => "volumeflow", "bitSize" => 15,"factor" => 0.1,"unit" => "l/min"},
  { "offset" => 24,"name" => "speed_R01", "bitSize" => 8, "unit" => "%"},
  { "offset" => 25,"name" => "speed_R02", "bitSize" => 8, "unit" => "%"},
  { "offset" => 26,"name" => "speed_R03", "bitSize" => 8, "unit" => "%"},
  { "offset" => 27,"name" => "relais_R04", "bitPos" => 0, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R05", "bitPos" => 1, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R06", "bitPos" => 2, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R07", "bitPos" => 3, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R08", "bitPos" => 4, "bitSize" => 1 },
  { "offset" => 27,"name" => "relais_R09", "bitPos" => 5, "bitSize" => 1 },
  { "offset" => 28,"name" => "heatquantity", "bitSize" => 32, "factor" => 0.001,"unit" => "kWh" },
]},


Beim OREGON-Modul werden SUB/Funktionen aufgerufen.

Code Auswählen Erweitern


my %types =
  (
   # THGR810 v3
   OREGON_type_length_key(0xfa28, 80) =>
   {
    part => 'THGR810', checksum => \&OREGON_checksum2, method => \&OREGON_common_temphydro,
   },
   # WTGR800 Temp hydro v3
   OREGON_type_length_key(0xfab8, 80) =>
   {
    part => 'WTGR800_T', checksum => \&OREGON_checksum2, method => \&OREGON_alt_temphydro,
   },
   # WTGR800 Anenometer v3
   OREGON_type_length_key(0x1a99, 88) =>
   {
    part => 'WTGR800_A', checksum => \&OREGON_checksum4, method => \&OREGON_wtgr800_anemometer,
   },
   # WGR800 v3
   OREGON_type_length_key(0x1a89, 88) =>
   {
    part => 'WGR800', checksum => \&OREGON_checksum4, method => \&OREGON_wtgr800_anemometer,
   },


Vielleicht könnte man auch im Signalduino-Modul die Parameter für die einzelnen IF so ablegen. Ich weiß nicht einmal wie diese Gebilde in Perl heißt ;-(.  Hash oder Array ?!

Jörg

[Ralf9]

Eher glaube ich, dass was mit der Auswertung der Daten nicht stimmt.
Also, z.B. ist die Nachricht länger oder kürzer und wird deshalb nicht erkannt.

Hallo Sidey,

ich habe mir mal die Protkollbeschreibung angeschaut.
Bei SensorTyp 30 (Temperatur) hat eine Nachricht  9 Byte beim Type 14 (rain) sind es 8 Byte,
aber beim Type 12 (Windsensor) sind es 13 Byte !

Sind die 13 Byte für die Firmware evtl zu lang?

Gruß Ralf

[Sidey]

Wo kan ich noch etwas anpassen ? Danke.

Hi Jörg,

ich habe soeben zwei Fehler behoben.

1. Das signalduino_un Modul hat die Hideki Nachrichten erhalten, das führt dazu, dass es ein anderes Modul nicht mehr erhält.
2. In der SIGNALduino_Hideki Funktion wird nach dem Startpattern (0x75) gesucht (10101110b). Ich habe mir die Protokollbeschreibung angesehen und festgestellt, dass die kürzeste Nachricht aus 64 Bit besteht. Es ist also ungünstig, wenn wir schon vorher erneut nach dem Startpattern suchen, denn das wird ja dann als Ende der Nachricht / Beginn einer neuen angesehen.

Damit wird die im Log geposteten Nachricht nun dekodiert. Ich denke, das wird so einige Probleme mit Hideki Sensoren beheben.
Ganz korrekt ist das mit den 64 Bit nun aber auch nicht. Die Korrekte Lösung wäre es, das Längenbit (#2) bereits in SIGNALduino_Hideki zu dekodieren und erst nach Länge+Checksumme nach dem Beginn einer Wiederholung zu suchen.

Was deinen anderen Post angeht, das sind Hashes.... Arrays gibt es in Perl nicht, die nennen sich Listen
Vom Prinzip kann man sich mit solchen hashes etwas sehr Modular aufbauen.
Das Beispiel von dir geht ja sogar so weit, dass in dem Hash die Ausgabe gesteuert wird.
Wie die Verarbeitung des Hashes da nun funktioniert weiss ich nicht.

Offset wird wohl in Bytes angegeben und aus bitsize wird wohl der Wert extrahiert.

Code Auswählen Erweitern


{ "firstbit" =>  0,"name" => "temperature_T01","lastbit" => 15,"factor" => 0.1,"unit" => "°C" },


Wäre vielleicht klarer zu verstehen.
Es ist halt die Frage, ob man ausschließlich Werte angibt, oder Funktionen.
Variante 1 ist solange sehr simpel, solange sich die Werte mit dem Muster verarbeiten lassen.
Eine Funktion benötigt man immer dann, wenn man noch was "individuelles braucht".

Man könnte beides verbinden und immer dann, wenn man etwas komplexes umrechnen muss noch eine Methode (optional) mit angeben

Code Auswählen Erweitern


{ "firstbit" =>  0,"name" => "temperature_T01","lastbit" => 15,"factor" => 0.1,"unit" => "°C" , method => sub { #eine komplexe Umrechnung} ,


Die Variante im Oregon Modul ist auch nicht schlecht, aber da der Schlüssel aus zwei Werten berechnet wird, auch etwas komplexer.

@Ralf: Nein die 13 Byte sind nicht zu lang. Wir verarbeiten ja beim Oregon Protokoll wesentlich längere.

Grüße Sidey

[Sidey]

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

Das Sollte kein Problem sein, da für jeden Wert eine funktion hinterlegt ist.
Ich habe im Beispiel anonyme Funktionen verwendet, da alles in einem Einzeiler zu erledigen war.

Für Standardfälle oder komplexere Berechnungen kann man jederzeit eine Funktion (sub) erzeugen und referenzieren.

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

Auch kein Problem, wobei ich das Gefühl habe, das wäre auch einfacher zu realisieren gewesen.

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

Tia, da bin ich mir noch nicht so klar.
Damit wir flexibel bleiben, wäre eine Funktion denkbar, die je nach Sensor halt befüllt wird.

Damit wir aber überhaupt mehrere Sensoren pro Protokoll definieren können, brauchen wir eine weitere Ebene in so einem Konfigurationshash:

Code Auswählen Erweitern


my %Sensordevices  = (
  "37"    =>
        {
            model => {
                'Besser 7009994' =>
                {
                           predec => sub { return shift },

                }
                'xyz 44344 Sensor =>
                {
                           predec => sub { return shift },
                }
                 ...


Je Sensor kann dann über eine valid Funktion eine Rückgabe erfolgen, ob der Sensor korrekt dekodiert wurde.
In der Anzahl ist man zunächst auch erst mal nicht eingeschränkt.

So im großen und ganzen ergibt sich mir nun ein Bild wie das funktionieren könnte.

Grüße Sidey

[pejonp]

...
ich habe soeben zwei Fehler behoben.
...

Hallo Sidey,

habe ein Update gemacht und werde das mal beobachten. Danke.

Jörg

[waschbaerbauch]

Nochmal wegen der zwei Versionen. Sobald ich die aus dem dev Tree installieren zeigt mir FHEM bei 'update check' ja an das es eine aktuellere Version gibt (das müsste dann Version 3.1 sein). Wenn ich nun wegen anderer Module ein 'update' mache, muss ich danach dann wieder den dev Tree vom SIGNALduino updaten, damit alles ist wie es sein soll?

[Hauswart]

Ja leider. Außer du exkludierst die Dateien von normalen Update.

[hjgode]

Ja leider. Außer du exkludierst die Dateien von normalen Update.

Auf der Fhem Wiki Seite zu Tablet UI habe dazu folgdendes gefunden:

Über update add https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master kann seit dem 24.12.2015 die URL zum normalen Updatebefehl von FHEM hinzugefügt werden. Mit einen "update check" sieht man dann gleich alle Updates aus beiden "Welten".

Demnach müsste doch

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

auch gehen. oder? In meinem Testsystem ging dies jedenfalls:
Nach einem "update add..." und dann "update all":

Code Auswählen Erweitern

signalduino
Got remote controls_signalduino.txt with 19 entries.
Got local controls_signalduino.txt with 16 entries.
List of new / modified files since last update:
UPD FHEM/firmware/SIGNALduino_uno.hex
UPD FHEM/firmware/SIGNALduino_promini328.hex
UPD FHEM/firmware/SIGNALduino_nano328.hex
UPD FHEM/00_SIGNALduino.pm
UPD FHEM/14_Hideki.pm
UPD FHEM/41_OREGON.pm
UPD FHEM/14_SD_WS.pm
UPD FHEM/14_SD_AS.pm
UPD FHEM/14_SD_WS07.pm
UPD FHEM/14_SD_WS09.pm
UPD FHEM/14_SIGNALduino_RSL.pm
UPD FHEM/90_SIGNALduino_un.pm

New entries in the CHANGED file

Sieht gut aus, oder?

~Josef