MAX und SIGNALduino?

[Ralf9]

Ich würde gerne die MAX! Module Signalduino tauglich machen, z.Z. ist mir allerdings noch unklar was ich da ändern müsste bzw. ob nicht erst die Firmware für den ESP und/oder das FHEM Modul zuerst ran müssen.
Das MAX Protokoll verwendet :

Code Auswählen Erweitern

Modulation 2-FSK
Center frequency 868.3Mhz
Frequence deviation 19Khz
Datarate 10Kbit
Preamble: 4 bytes (1010...)
Syncword: 0xc626c626
 

Im FHEM Wiki steht zu MAX:
Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)

Die ACK quittierung wird in der CUL Firmware gemacht. Da müsste man in der CUL Firmware schauen was die sonst noch mit den max Nachrichten macht.
Wenn die ACK quittierung zeitkritisch ist, dann muß sie in der Signalduino Firmware gemacht werden.

Laut
https://forum.fhem.de/index.php?topic=8437.0
ist es in der culw als moritz zu finden

Dies müsste dann in die sduino firmware eingebaut werden:
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/clib/rf_moritz.c

Thema Tester : Soviele mit MAX wird es nicht mehr geben, allerdings müsste HomeMatic doch auch als Test gehen, da IMHO "nur" das SyncWord sich von MAX unterscheidet.

[Ralf9]

Ich habs mal mit Homematic getestet, damit konnte ich was empfangen

Code Auswählen Erweitern

CW0007,0246,0307,04E9,05CA,06FF,070C,0845,0D21,0E65,0F6A,10C8,1193,1203,1322,14F8,1534,173F,1916,1B43,1C40,1D91,23E9,242A,251F,2611,3D0F,3E01,404D,4141,4258,435F,4400

Dies kommt von einem Fensterkontakt

Code Auswählen Erweitern

MN;D=0CE2385543079F7B57330E7E864384;N=15;r;
MN;D=0CE3395442069E7A56320F7E4E4784;N=15;r;
MN;D=0CE03A5741059D7955310C7E864384;N=15;r;
MN;D=0CE13B5640049C7854300D7E4E4884;N=15;r;
MN;D=0CEE4C69370B9B77532F0A7E864287;N=15;r;
MN;D=0CEF4D68360A9A76522E0B7E4E4484;N=15;r;
MN;D=0CEC4E6B35099975512D087E864485;N=15;r;
MN;D=0CED4F6A34089874502C097E4E4484;N=15;r;
MN;D=0CEA405D4B3F67431FFBD62E864283;N=15;r;
MN;D=0CEB415C4A3E66421EFAD72E4E4383;N=15;r;
MN;D=0CE8425F493D65411DF9D42E864387;N=15;r;
MN;D=0CE9435E483C64401CF8D52E4E4384;N=15;r;
MN;D=0CD634515F23835F3B17F26E864384;N=15;r;
MN;D=0CD735505E22825E3A16F36E4E4386;N=15;r;
MN;D=0CD436535D21815D3915F06E864384;N=15;r;
MN;D=0CD537525C20805C3814F16E4E4386;N=15;r;


Und hier ist die Homematic config mit dem sync von MAX:

Code Auswählen Erweitern

CW0007,0246,0307,04C6,0526,06FF,070C,0845,0D21,0E65,0F6A,10C8,1193,1203,1322,14F8,1534,173F,1916,1B43,1C40,1D91,23E9,242A,251F,2611,3D0F,3E01,404D,4141,4258,435F,4400

Du kannst auch mal beim cc1101 Register 0 die Werte 6 oder 1 versuchen

Code Auswählen Erweitern

00 IOCFG2
-1: Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty.
-6: Asserts when sync word has been sent / received, and de-asserts at the end of the packet.
-7: Asserts when a packet has been received with CRC OK. De-asserts when the first byte is read from the RX FIFO.

Hier ist zur Info das Register 7

Code Auswählen Erweitern

07 PKTCTRL1
-xC: Enable automatic flush of RX FIFO when CRC is not OK. This requires that only one packet is in the RXIFIFO and that packet length is limited to the RX FIFO size.
     two status bytes will be appended to the payload of the packet. The status bytes contain RSSI and LQI values, as well as CRC OK

Falls es jemand testen will, diese cc1101 Registerkonfig funktioniert nur mit meiner sduino Firmware

Gruß Ralf

[Wzut]

Das macht doch schon mal Hoffnung auf mehr  , THX
Der Duino ist bestellt und sowie er bei mir ist lege ich los und melde mich wieder.

[Wzut]

Das hat mir jetzt natürlich doch keine Ruhe gelassen und ich habe es nochmal aufs Brett gesteckt.
Prima mit Register 0 = 7.
Bsp :

Code Auswählen Erweitern

2023.11.01 19:00:56 4: signal/msg READ: MN;D=0B6E0630163CD912345600102E83;N=15;r;
2023.11.01 19:00:56 4: signal/msg READ: MN;D=0B6E0002123456163CD900002088;N=15;r; 
Was ich direkt sehe : 163CD9 eines meiner Geräte , 123456 FHEM , d.h. Quell und Ziel Addr.
Den Rest (payload, etc) muss mir noch vornehmern. Dazu würde ich gern die Nachricht direkt zu 14_CUL_MAX weitergeben.
Was könnte ich quick & dirty tun ? Ich vermute ich benötige einen eignen Block im hash ProtocolListSIGNALduino in der signalduino_protocols.pm
Ein simples "34:CUL_MAX" => '^0.*' in der 00_SIGNALduino.pm reicht ja nicht.

[Ralf9]

Ich habs mir mal angeschaut.

in der 14_CUL_MAX steht:
$hash->{Match}     = "^Z";

in der 00_CUL.pm steht in der matchList
"1:CUL_MAX" => "^Z........................",

in die matchListSIGNALduino müsste dann (Die regex von der matchList und vom Clientmodul sollten gleich sein)
"38:CUL_MAX" => "^Z.*",

Mit einem "get sduino raw Z0B6E0630163CD912345600102E83" müsste dann ein dispatch zum CUL_MAX Modul erfolgen

[Ralf9]

In der parse Routine von der 00_CUL.pm habe ich dies gefunden. Ist das notwendig, damit in der parse Routine vom 14_CUL_MAX Modul die Nachricht verarbeitet werden kann?

Code Auswählen Erweitern

  } elsif($fn eq "Z" && $len >= 21) {              # Moritz/Max
    my $src = lc(substr($dmsg,9,6));
    if(exists($modules{MAX}{defptr}{$src}) && defined($rssi))
    {
     $modules{MAX}{defptr}{$src}{helper}{io}{$name}->{time} = gettimeofday();
     $modules{MAX}{defptr}{$src}{helper}{io}{$name}->{rssi} = $rssi;
     $modules{MAX}{defptr}{$src}{helper}{io}{$name}->{raw} = $dmsg;
    }

[Ralf9]

Ich habs mal getestet

Zusätzlich muss auch noch in die $clientsSIGNALduino noch
."CUL_MAX:"

Dann ein define
define MAX_163CD9 CUL_MAX 163CD9

dann (die letzten beiden Hex Byte müssen entfernt werden)
get sduino raw Z0B6E0630163CD91234560010

Code Auswählen Erweitern

2023.11.01 22:04:36.294 5: sduinoD: dispatch Z0B6E0630163CD91234560010
2023.11.01 22:04:36.295 5: MAX_163CD9, IODev sduinoD, len 11, msgcnt 6E, msgflag 06, msgType ShutterContactState, src 163cd9, dst 123456, group 0, payload 10, rssi 0
2023-11-01 22:04:36.297 CUL_MAX MAX_163CD9 ???

[Wzut]

1. der Teil in der 00_CUL.pm wird nur gebraucht wenn mehrere CULs im Einsatz sind um den "besten" zum senden zu finden, ist jetzt erst einmal egal.

2. klappt das bei mir mit get signal raw Z0B6E0630163CD9123456001020 nicht , ich bekomme im Eventmonitor :

Code Auswählen Erweitern

23.11.02 14:04:37 5: signal: command for gets:  Z0B6E0630163CD91234560010
2023.11.02 14:04:37 5: AddSendQueue: signal: Z0B6E0630163CD91234560010 (1)
2023.11.02 14:04:37 5: signal SW: Z0B6E0630163CD91234560010
2023.11.02 14:04:37 5: signal/RAW READ: /Unsupported command
2023.11.02 14:04:37 5: signal/RAW READ: Unsupported command/
2023.11.02 14:04:37 4: signal/msg READ: Unsupported command
2023.11.02 14:04:37 5: signal/noMsg Parse: Unsupported command
["#FHEMWEB:WEB","FW_okDialog('raw: Unsupported command')",""]
2023.11.02 14:04:37 4: signal/HandleWriteQueue: nothing to send, stopping timer
3. aber da ich eine faule Sau bin wollte ich eh nicht jedes Telegramm von Hand kopieren und wieder einfügen um es in CUL_MAX durch die Parse sub zu jagen. Ich wollte das 00_SIGNALduino das als gültiges Telegramm erkennt und direkt Dispatch anwirft.

[Ralf9]

Verwendest Du das orginale 00_SIGNALduino Modul vom fhem update?
Da gibts kein get raw, das wurde von Sidey ausgebaut.

Dafür ist mein alternatives 00_SIGNALduino Modul notwendig.

Damit das 00_SIGNALduino das als gültiges Telegramm erkennt und direkt Dispatch macht, das kommt noch.
Dafür ist eine neue Protokoll Id notwendig und vor dem Dispatch müssen die beiden letzten Hexbyte entfernt werden

[Wzut]

1. Das ist schon deine Version :

Code Auswählen Erweitern

# $Id: 00_SIGNALduino.pm 347 2021-06-24 20:00:00Z v3.4.7-Ralf9 $
in der Detailansicht des Device und auswahl des raw Dropdown passiert beim drücken auf get gar nichts, wenn ich den get raw in der Kommandozeile absetze erhalte ich ein leeres PopUp als Quittung (siehe Anhang)
Für mich siht das aus als wenn nicht raw unbekannt wäre sondern das was ich da übergebe.

2. Wenn die beiden letzten Bytes entfernt werden fehlt doch der RSSI Wert oder sehe ich da deine Erklärung des Register 7 mit C falsch ? Der CUL schickt den RSSI Wert auch nicht im Telegramm mit sondern auf anderem Weg.
Von mir aus muß der Aufwand aber nicht sein, ich kann die beiden Bytes auch in CUL_MAX abschneiden.

[Ralf9]

Dies ist nicht die aktuelle Version.
Die aktuelle ist

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/RFFHEM/dev/controls_dev_ralf9_signalduino.txtversionmodul  v3.4.16-dev_ralf_23.07.
versionprotoL v3.4.16-dev_ralf_23.07.

Es gibt in den nächsten Tagen eine neue Version von meinem 00_SIGNALduino Modul mit der dann mit einer neuen Protokoll ID die empfangenen Max Nachrichten zum CUL_MAX Modul weitergeleitet werden.

Die beiden letzten Bytes werden dann im 00_SIGNALduino Modul entfernt und die RSSI in den hash vom sduino geschrieben, von dort wird er dann vom CUL_MAX Modul geholt.


In der rf_moritz.c  steht:

/* We have to keep at least 20 ms of silence between two sends
   * (found out by trial and error). ticks runs at 125 Hz (8 ms per tick),
   * so we wait for 3 ticks.
   * This looks a bit cumbersome but handles overflows of ticks gracefully.
   */

Mir ist nicht klar zu was dies notwendig ist.
Im 00_cul und 00_SIGNALDuino Modul gibts eine Sendewarteschlange durch die eine kleine Pause zwischen den Sendebefehlen eingelegt wird.

[Wzut]

Dies ist nicht die aktuelle Version.

2021 kam mir auch komisch vor als ich es so gepostet sah ....

Warum etwas und wie im CUL für MAX gemacht wird : Keine Ahnung, das war alles lange vor meiner Zeit. 

[Ralf9]

Hier ist eine neue Version meines 00_SIGNALduino.pm Moduls
https://github.com/Ralf9/SIGNALduinoADV_FHEM/blob/master/FHEM/00_SIGNALduino.pm
https://github.com/Ralf9/SIGNALduinoADV_FHEM/blob/master/FHEM/lib/signalduino_protocols.pm

versionmodul v3.4.17-ralf_07.11.23
versionprotoL v3.4.17-ralf_07.11.23

Es gibt eine neue ID 215 für den Empfang von MAX

Gruß Ralf

[Wzut]

Das sieht ja schon richtig gut aus
Allerdings darf man nicht fix die ersten 26 Zeichen an CUL_MAX weitergeben, die Telegrammlänge ist je nach Kommando und Payload verschieden.
Die ersten beiden Bytes sind die Länge.
Ich habe die sub SIGNALduino_MAX so geändert :

Code Auswählen Erweitern

my $len = (hex(substr($dmsg, 0, 2)) * 2) + 2;
return (1,substr($dmsg, 0, $len));
Damit decodiert 14_CUL_MAX bzw 10_MAX schon mal so einiges, ich muss jetzt natürlich erst einmal diverse Dinge testen.
Thema Telegrammlänge :
In der 14_CUL_MAX findet sich noch von meinem Vorgänger :

Code Auswählen Erweitern

# Attention: there is a limit in the culfw firmware: It only receives messages shorter than 30 bytes (see rf_moritz.h)
ich selbst habe dann noch eine Prüfung auf minestens 20 Byte eingebaut. Macht das Sinn dies noch in die sub mit zu übernehmen und fehlerhafte Telegramme so erst gar nicht via dispatch weiter zu geben ? 
 

[Ralf9]

Allerdings darf man nicht fix die ersten 26 Zeichen an CUL_MAX weitergeben, die Telegrammlänge ist je nach Kommando und Payload verschieden.

Es müsste doch auch reichen einfach die letzten beiden Byte zu entfernen.

In der 00_CUL steht:

Code Auswählen Erweitern

} elsif($fn eq "Z" && $len >= 21) {              # Moritz/MaxDemnach ist die minimale MAX-Nachrichtenlänge 20 Zeichen und in der signalduino_protocols.pm müsste bei length_min eingetragen werden:

Code Auswählen Erweitern

length_min      => '24',     # 12 Byte

# Attention: there is a limit in the culfw firmware: It only receives messages shorter than 30 bytes (see rf_moritz.h)

Demnach können MAX-Nachrichten maximal 30 Zeichen lang sein.