Signalduino - Atlantic und Focus Security China Devices

[HomeAuto_User]

Nabend, kleine Falle welche ich nicht verraten hatte  weil eben Entwicklung.
Schau mal in deiner 00_SIGNALduino.pm und passe die Zeile bitte an.

Code Auswählen Erweitern

"17:SD_UT" => '^P(?:14|29|30|34|46|69|76|81|83|86|91|91.1|92)#.*', # universal - more devices with different protocols

Da fehlt bestimmt bei dir noch die 92 drin.
Zusätzlich musst du in der signalduino_protocols.hash Datei folgendes anpassen unter ID 91 + 91.1

Code Auswählen Erweitern

clientmodule => 'SD_UT',
preamble => 'P91#', # prepend to converted message

Code Auswählen Erweitern

clientmodule => 'SD_UT',
preamble => 'P91.1#', # prepend to converted message

FHEM RESTART und ein neuer Versuch

[Harst]

Ich lerne, aber jetzt Zickt die Checksum:

Code Auswählen Erweitern

2019.01.09 00:20:30 4 : sduino433/msg READredu: MS;P1=814;P3=-403;P4=-805;P5=408;P6=-4010;D=56545313145313131454545314545454545314531314545454531453131454545314531454;CP=5;SP=6;R=0;O;m2;
2019.01.09 00:20:30 4 : sduino433: Matched MS Protocol id 91.1 -> Atlantic security
2019.01.09 00:20:30 5 : sduino433: Starting demodulation at Position 3
2019.01.09 00:20:30 5 : sduino433: Found wrong signalpattern, catched 35 bits, aborting demodulation
2019.01.09 00:20:30 4 : sduino433: Decoded MS Protocol id 91.1 dmsg P91.1#6E20B0B14 length 36 RSSI = -74
2019.01.09 00:20:30 5 : sduino433 Dispatch: P91.1#6E20B0B14, test ungleich: disabled
2019.01.09 00:20:30 5 : sduino433 Dispatch: P91.1#6E20B0B14, -74 dB, dispatch
2019.01.09 00:20:30 5 : sduino433: dispatch P91.1#6E20B0B14
2019.01.09 00:20:30 4 : sduino433: SD_UT protocol 91.1, bitData 011011100010000010110000101100010100
2019.01.09 00:20:30 4 : sduino433: SD_UT device MD_210R check length & Protocol OK
2019.01.09 00:20:30 4 : sduino433: SD_UT device from Atlantic Security - check XOR (15) FAILED! rawData=6E20B0B14


Horst

[HomeAuto_User]

Hallo Horst,
hast du Glück, das ich eine nächtliche ungeplante Küchenwischung vornehmen durfte, so lese ich kurz nochmal zum runter kommen.

Das Problem mit dem Xor ist am Anfang des Fadens erläutert. Padding Bit. Bin leider nicht am Rechner, sonst hätte dir den Link geschickt.

Aufgrund das das Modul noch getestet wird, sind diese jetzigen Anpassungen noch nicht in der dev-r33 erfasst.

Gute Nacht zum 2.

[jochen_f]

Hallo,

ich habe es gerade kurz getestet. Beim Keepalive ist periodically und event vertauscht. Ansonsten alles super.

Das mit dem Padding Bit muss noch geklärt werden. Bei mir habe ich die 91.1 komplett gelöscht und nutze stattdessen meinen MU Fallback Patch.

Gruß, Jochen

[Harst]

Hallo,

Ich habe meine Meldung P91.1#6E20B0B14 mal durchgerechnet. Padding ist hier richtig gemacht. Und xor(  6 e 2 0 b 0 b 1 4 ) ergibt f, also 15. Das erscheint mir korrekt.

Und jetzt habe ich im Modul gesehen, dass auf 0 getestet wird und auch nur die Stellen 1-8, Zumindest bei 91.1 müsste 1-9 auf 15 getestet werden. Ich sehe später nach, ob das auch für die anderen Sensoren gilt.

Horst

[Harst]

Ich kämpfe mit der neuen Programmiersprache:

Bei 91.1 muss die Checksumme über alle Nibble gerechnet werden, also 1..9
Vorher muss die Meldung invertiert werden.

Dann stimmt die Checksumme, aber es werden leider keine Devices angelegt.
Es kommt zudem immer die Meldung "batteryState unknown: ok" (oder warning)

Grüße

Horst

[Harst]

Hallo,

ich habe jetzt eine Version, die bei mir alles macht, nur beim Anlagen der Devices gibt es immer defineDeviceType. Wenn ich das dann setze ist alles ok. Geändert habe ich:

->Meldung invertiert.
->Checksum nicht auf das letzte Bit getestet, da das ja noch ein Problem darstellt (hätte da eine Idee für den Decoder)
->Checksumme mit dem Nibble 9 getestet, ergibt 0 (oder 1)
->Battery, open und Alarm reweils 0/1 vertauscht. Wahrscheinlich eine Folge des Invertierens
->Der Rüttelkontakt setzt das Sabotage-Bit nie, der Gas-Sensor immer, also entfernt.
->Battery auf ok und low gesetzt, scheint man jetzt so zu machen. Ich habe auch alle Geräte auf Battery getestet, unter 2,2V wurde das erzeugt.

Ich hoffe, den richtigen Programmierstil erwischt zu haben

Horst

[HomeAuto_User]

Hallo,

Hallo,

ich habe jetzt eine Version, die bei mir alles macht, nur beim Anlagen der Devices gibt es immer defineDeviceType. Wenn ich das dann setze ist alles ok. Geändert habe ich:

->Meldung invertiert.
->Checksum nicht auf das letzte Bit getestet, da das ja noch ein Problem darstellt (hätte da eine Idee für den Decoder)
->Checksumme mit dem Nibble 9 getestet, ergibt 0 (oder 1)
->Battery, open und Alarm reweils 0/1 vertauscht. Wahrscheinlich eine Folge des Invertierens
->Der Rüttelkontakt setzt das Sabotage-Bit nie, der Gas-Sensor immer, also entfernt.
->Battery auf ok und low gesetzt, scheint man jetzt so zu machen. Ich habe auch alle Geräte auf Battery getestet, unter 2,2V wurde das erzeugt.

Ich hoffe, den richtigen Programmierstil erwischt zu haben

Horst

komisches Verhalten, das sollte eigendlich alles angelegt haben weil ich dies ja auch immer durchteste!

Code Auswählen Erweitern

->Battery, open und Alarm reweils 0/1 vertauscht. Wahrscheinlich eine Folge des Invertierens
Ich vermute du hast eine alte Definition, deswegen ist alles getauscht.

Code Auswählen Erweitern

->Der Rüttelkontakt setzt das Sabotage-Bit nie, der Gas-Sensor immer, also entfernt.
Was ist bei dir der Rüttelkontakt?

MfG

EDIT: habe ich es richtig gedeutet, das die Sabotage nur beim MD_210R & MD_2018R genutzt wird?

[Harst]

Hallo Marko,

Der Rüttelkontakt/Vibration ist der MD_2018
Nur der MD_210R verwendet das Sabotagebit
  der Rüttelkontakt MD_2018R hat dazu keine Hardware
  der Gas-Sensor MD_2003R setzt es immer, egal wie der Schalter wirklich steht (deshalb überschrieben)

Das einzig wichtige wäre die Checksumme, denn die verhindert das Erkennen der Meldungen bei 2 Sensoren ganz oder meistens. Das habe ich temporär mit dem <=1 erreicht. Auf Dauer muss da natürlich eine richtige Lösung her.

Horst

PS: Wie kann man beim Wiki mitmachen? Die Hilfe zum Registrieren stimmt nicht mehr und einen Knopf dazu habe ich nicht gefunden.

[HomeAuto_User]

Hi,

Das einzig wichtige wäre die Checksumme, denn die verhindert das Erkennen der Meldungen bei 2 Sensoren ganz oder meistens. Das habe ich temporär mit dem <=1 erreicht. Auf Dauer muss da natürlich eine richtige Lösung her.

Die Anfrage ist raus ob wir das wie hier vorgeschlagen nutzen können!

PS: Wie kann man beim Wiki mitmachen? Die Hilfe zum Registrieren stimmt nicht mehr und einen Knopf dazu habe ich nicht gefunden.

Meinst du die FHEM Wiki oder eine andere was das Modul oder ähnliches betrifft?

[Harst]

Hallo,

das mit dem Wiki habe ich gefunden, sobald ich es gefragt hatte.
Und die Antwort ist auch schon da.

Danke

Horst

[HomeAuto_User]

Hallo Harst,
kannst du bitte von dem Wassermelder ein paar RAWMSG sammeln und mal posten.

Liebe Grüße

[Harst]

Hallo,

das mit dem Wassersensor hat etwas gedauert, er war eingemottet, weil der Keller noch vorbereitet werden muss. Die RAW-Daten liegen auf
   https://wiki.fhem.de/wiki/Signalduino_Rawdaten#MD-230R
bis wir uns auf eine andere Methode geeinigt haben.

Horst