Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[gandi1791]

Wenn Du den miniCul hast, dann probier ihn mal mit der SIGNALduino Firmware aus.
Lade dazu die Entwickler Version des SIGNALduino Modules und dann könntest Du glück haben, dass es geht.


Grüße Sidey

Vielen Dank, werde ich probieren und Rückmelden, ob's gefunzt hat.

[Ralf9]

Hallo,

lesen hier einige mit die eine white- oder blacklist verwenden.

Ich würde gerne folgendes zur Diskussion stellen. Mich würde auch Eure Meinung interessieren.

Z.Zt. gibt es recht viele Änderungen an der signalduino_protocols.hash.
Es sind einige neue Protokolle dazukommen, es wurden Protokolle entfernt und es wurden Protokolle zusammengefasst.
Momentan werden die dadurch freiwerdenden Protokoll-IDs wieder für neue Protokolle verwendet.
Ist dies für Euch ok, oder wäre es besser die neuen Protokolle hinten anzuhängen und die Lücken frei lassen.

Ich habe mal versucht die letzten Änderungen zusammenzufassen:

Code Auswählen Erweitern

alt ID 38  ---- neu ID 0.1 => other Sensors  (380 | 9650), CUL_TCM97001 Typ - AURIOL | Mebus,  LIDL Wetterstation

alt ID 68  ---- neu ID 0.3 => Pollin PFR-130

- ID 20 Livolo  removed, da keine USER Daten und Protokoll "halb definiert" was zu sehr vielen u20 führt mit willkührlichen Daten
   https://forum.fhem.de/index.php/topic,38831.msg338664.html#msg338664

- added ID 14 LED X-MAS Chilitec model 22640

- ID22 changed (old ID from https://forum.fhem.de/index.php?topic=35844.0 are same ID33 | Userfeedback, all RAWMSG after update FW decoded as ID22 @ ID33 double, new device with readings are correct temp @ hum)

- added new remote LED HAMULiGHT to ID 22

Gruß Ralf

[RappaSan]

Moin Ralf,

ich entdecke nichts, was bei mir benötigt wird. Recycling ist somit OK.

[RaspiLED]

Für mich ist Recycling auch okay

Gruß Arnd


Gesendet von iPhone mit Tapatalk

[pejonp]

....
Z.Zt. gibt es recht viele Änderungen an der signalduino_protocols.hash.
Es sind einige neue Protokolle dazukommen, es wurden Protokolle entfernt und es wurden Protokolle zusammengefasst.
Momentan werden die dadurch freiwerdenden Protokoll-IDs wieder für neue Protokolle verwendet.
Ist dies für Euch ok, oder wäre es besser die neuen Protokolle hinten anzuhängen und die Lücken frei lassen.

Ich habe mal versucht die letzten Änderungen zusammenzufassen:

Code Auswählen Erweitern

alt ID 38  ---- neu ID 0.1 => other Sensors  (380 | 9650), CUL_TCM97001 Typ - AURIOL | Mebus,  LIDL Wetterstation

alt ID 68  ---- neu ID 0.3 => Pollin PFR-130
.....
[/quote]

Hallo Ralf,

zur Zeit habe ich lange nichts mehr mit SignalDuino gemacht, es läuft einfach. Ist auch sehr schön so. Vielen Dank an alle.
Den Pollin PFR-130 verwende ich und habe das damals auch in die SignalDuino  bzw. 14_CUL_TCM97001.pm Module eingebaut. Wenn die Funktionweise/ Erkennung weiter gegeben ist, währe das ok.
Wer verwaltet oder pflegt jetzt das Modul 14_CUL_TCM97001.pm ?
Vielleicht sollte im Wiki mal die erkannten Sensoren und die zur Zeit aktuelle Version die in FHEM verteilt wird ergänzt werden. Ab und zu lese ich mit, bin aber nicht mehr auf dem laufenden welche Version die stabile ist.

pejonp

[yoda_gh]

lesen hier einige mit die eine white- oder blacklist verwenden.

Ich würde gerne folgendes zur Diskussion stellen. Mich würde auch Eure Meinung interessieren.

Z.Zt. gibt es recht viele Änderungen an der signalduino_protocols.hash.
Es sind einige neue Protokolle dazukommen, es wurden Protokolle entfernt und es wurden Protokolle zusammengefasst.
Momentan werden die dadurch freiwerdenden Protokoll-IDs wieder für neue Protokolle verwendet.
Ist dies für Euch ok, oder wäre es besser die neuen Protokolle hinten anzuhängen und die Lücken frei lassen.

Auch ich sehe in Deiner Liste nix relevantes aus meiner Whitelist (kann man das sinnvoll ohne einsetzen? ). Daher würde mich persönlich Recycling auch nicht stören, auch wenn ich das global-galaktisch betrachtet für eine unglückliche Idee halte...

[Sidey]

Daher würde mich persönlich Recycling auch nicht stören, auch wenn ich das global-galaktisch betrachtet für eine unglückliche Idee halte...

Grundsätzlich oder eher darauf bezogen, dass man nicht ein paar Wochen abwartet?

[HomeAuto_User]

Hallo,

Hallo,

lesen hier einige mit die eine white- oder blacklist verwenden.

Ich würde gerne folgendes zur Diskussion stellen. Mich würde auch Eure Meinung interessieren.

Z.Zt. gibt es recht viele Änderungen an der signalduino_protocols.hash.
Es sind einige neue Protokolle dazukommen, es wurden Protokolle entfernt und es wurden Protokolle zusammengefasst.
Momentan werden die dadurch freiwerdenden Protokoll-IDs wieder für neue Protokolle verwendet.
Ist dies für Euch ok, oder wäre es besser die neuen Protokolle hinten anzuhängen und die Lücken frei lassen.

Ich habe mal versucht die letzten Änderungen zusammenzufassen:

Code Auswählen Erweitern

alt ID 38  ---- neu ID 0.1 => other Sensors  (380 | 9650), CUL_TCM97001 Typ - AURIOL | Mebus,  LIDL Wetterstation

alt ID 68  ---- neu ID 0.3 => Pollin PFR-130

- ID 20 Livolo  removed, da keine USER Daten und Protokoll "halb definiert" was zu sehr vielen u20 führt mit willkührlichen Daten
   https://forum.fhem.de/index.php/topic,38831.msg338664.html#msg338664

- added ID 14 LED X-MAS Chilitec model 22640

- ID22 changed (old ID from https://forum.fhem.de/index.php?topic=35844.0 are same ID33 | Userfeedback, all RAWMSG after update FW decoded as ID22 @ ID33 double, new device with readings are correct temp @ hum)

- added new remote LED HAMULiGHT to ID 22

Gruß Ralf

ich melde mich mal kurz ebenso zu Wort.
Die vielen Änderungen die vorgenommen werden in der signalduino_protocols.hash Datei bitte ich zu entschuldigen für die User der Nutzung von black und whitelistID´s.
Da ich die Bearbeitung vornehme, so bitte ich alle User bei Fragen, gern mich selbst anzuschreiben via PN bei Fragen, sollte ich bzw. wir nicht alles in der changelog festhalten was relewant ist.

Die Umarbeitung / Anpassung der Liste bzw. die Erweiterung der Dokumentation basiert darauf, bestehende Protokolle zu implementieren, alte "stille" Protokolle zu prüfen ggf. zu ersetzen. Kurzum, es wird Ordnung geschaffen weil vieles hineingenommen war aber auch unvollständige "Leichen" schlummern.

Die Änderungen kann auch jeder hierüber https://github.com/RFD-FHEM/RFFHEM/commits/dev-r33 verfolgen.

MfG Marco

[yoda_gh]

Grundsätzlich oder eher darauf bezogen, dass man nicht ein paar Wochen abwartet?

Sagen wir mal so: wenn es keine recht zwingenden Gründe gibt (Werte-Überlauf, Code nur schwierig zu warten, etc.), würde ich es grundsätzlich vermeiden, IDs neu zu belegen, die der User sieht.

Ein paar Wochen ändern daran m.E. wenig - ich habe z.B. Phasen, wo ich mich Monate kaum um meine FHEM-Installation kümmere, da soll die einfach laufen - und wenn dann nach einem Update subtil etwas anders ist, ist das immer mühsam...

Ordnung zu schaffen ist dagegen immer gut, und wenn dafür ID-Änderungen zwingend sind, nur zu!

[jochen_f]

Hallo Ralf,

danke, das war erfolgreich

Code Auswählen Erweitern

2018-04-11 22:16:01 SIGNALduino sduino433 DMSG U79#6E4271F19
und der Erschütterungsmelder geht auch:

Code Auswählen Erweitern

2018-04-11 22:28:12 SIGNALduino sduino433 DMSG U79#E97E55BB1

der CO-Sensor hat sich nur einmal beim Einlegen der Batterien gemeldet.

jetzt muss ich mich dann wohl damit beschäftigen, wie man daraus Schalter in FHEM macht. Das mit dem Event und dem Dummy kenne ich, aber das ist ja nur eine Notlösung.

Danke

Horst

Mit der aktuellen Version funktioniert es nicht mehr, da die Länge des Protokoll-Strings für ID 79 jetzt auf 12 begrenzt ist, das Atlantic's security Protokoll aber 36 Zeichen lang ist. Da muss jetzt wohl doch eine neue ID her.

Gruß, Jochen

[HomeAuto_User]

Frohe Weihnachten!

@Jochen, sende mal bitte RAWMSG Nachrichten zu. Eine neue ID ist möglich weil die 79er auf das eine Klingel zugeschnitten wurde. Die Ergänzung würde ich für dich vornehmen.

Liebe Grüße Marco

[jochen_f]

Hallo,

hier ein paar Nachrichten:

Code Auswählen Erweitern


READ: MU;P0=800;P1=-813;P2=394;P3=-410;P4=-3992;D=0123030303030303012121230301212304230301212301230301212123012301212303012301230303030303030121212303012123042303012123012303012121230123012123030123012303030303030301212123030121230;CP=2;R=46;
READ: MU;P0=400;P1=-396;P2=813;P3=-812;P4=-3994;D=012123012301212121230121230303012121230124012123030123012123030301230123030121230123012121212301212303030121212301240121230301230121230303012301230301212301230121212123012123030301212123012;CP=0;R=40;
READ: MU;P0=406;P1=-402;P2=802;P3=-805;P4=-3994;D=012123012301212121212121230303012123030124012123030123012123030301230123030121230123012121212121212303030121230301240121230301230121230303012301230301212301230121212121212123030301212303012;CP=0;R=52;
READ: MU;P0=809;P1=-398;P2=-807;P3=404;P4=-3990;D=0102310231010101023101023232310101023104310102323102310102323231023102323101023102310101010231010232323101010231043101023231023101023232310231023231010231023101010102310102323231010102310;CP=3;R=42;


Im Moment habe ich einfach eine Kopie vom alten VTX-BELL Eintrag gemacht und auf eine neue bisher ungenutzte ID gemappt:

Code Auswählen Erweitern


"91" => ## Atlantic Security / Focus Security China Devices
{
name => 'atlantic security',
comment => 'Atlantic security',
id => '91',
knownFreqs => '',
zero => [-2,1],
one => [-1,2],
start => [-15,1],
clockabs => 330,
format => 'twostate', #
preamble => 'u91#', # prepend to converted message
length_min => '36',
length_max => '36',
},


Gruß, Jochen

[HomeAuto_User]

Hallo,

hier ein paar Nachrichten:

.....

Im Moment habe ich einfach eine Kopie vom alten VTX-BELL Eintrag gemacht und auf eine neue bisher ungenutzte ID gemappt:

Code Auswählen Erweitern


"91" => ## Atlantic Security / Focus Security China Devices
{
name => 'atlantic security',
comment => 'Atlantic security',
id => '91',
knownFreqs => '',
zero => [-2,1],
one => [-1,2],
start => [-15,1],
clockabs => 330,
format => 'twostate', #
preamble => 'u91#', # prepend to converted message
length_min => '36',
length_max => '36',
},


Gruß, Jochen

danke Jochen.
Um was für einen Sensor handelt es sich bei dir? Ein Erschütterungssensor?
Mit der Bezeichnung Atlantic security kann ich nicht viel anfangen. Hat der Sensor noch eine Modellbezeichnung?
Welche Funktionen hat der Sensor alles? Diesen könnte man gern auch noch einbinden um nicht immer ein DOIF zu nutzen, wenn er noch nirgends implementiert ist.

MfG

[jochen_f]

Hallo,

es scheint sich hier um eine Familie an Sensoren zu handeln, die beim Chinesen unter Atlantic'S oder Fokus kompatibel bezeichnet werden.

In meinem Fall ist es ein MD-210R, ein Tür- bzw Fenstersensor. Dieser meldet alle Zustandsänderungen. Zu bekommen ist er z.B. als Original hier:

https://www.amazon.de/dp/B00FGSFV5K/

Ein Manual findet man hier:

https://fccid.io/QOAMD-210R/User-Manual/User-Manual-1853455

Das Protokoll scheint aber entgegen dem Manual eher wie folgt zu sein:

1. 24bit Device-ID
2. 8bit Kommando
3. 4bit Prüfsumme

Beim Türkontakt scheint das Kommando zu sein:

1ab10001
a:Tür zu = 1
b: Sabotage Kontakt zu = 1
Möglich, dass es auch noch ein Bit für Batterie leer gibt.

Wie die Prüfsumme genau gebildet wird, weiß ich nicht, es scheint mir aber eine gewichtete Summe zu sein. Definitiv keine CRC oder ähnliche komplexere Funktion.

Es gibt aber noch weitere Sensoren mit dem selben Protokoll. Auf Seite 64 dieses Themas hat jemand CO Sensoren und Erschüttetungsmelder. Es gibt wohl auch noch Fernbedienungen.
Das ganze wahlweise mit 433 oder 868 MHz.

Gruß, Jochen

[Harst]

Der MD201R hat 3 Bit mit Daten, eins für die beiden Reed-Schalter, eins für den externen Kontakt und eins für den Gehäuseschalter.
Das letzte Bit hinter den Daten ist eigentlich immer 1, wird aber nicht aller erkannt.

Das Gerät ist scheinbar recht sendestark, ich habe es im Altbau im Keller bei 70cm dicken Wänden und der Signatuino ist im ersten Stock.

Der Reed-Schalter zeigt Tür auf/zu, der externe Kontakt ist als Schlossschalter für Abgeschlossen/Offen gesetzt.

define Kellertuer_notify_1 notify sduino433:DMSG.U79#6E4271F.* set Kellertuer closed
define Kellertuer_notify_2 notify sduino433:DMSG.U79#6E4271B.* set Kellertuer open
define Kellertuer_notify_3 notify sduino433:DMSG.U79#6E42717.* set Kellertuer locked

Bei Locked sind dann natürlich 2 Schalter gesetzt.

Horst