MAX und SIGNALduino?

Begonnen von Ralf9, 30 Oktober 2023, 22:38:14

Vorheriges Thema - Nächstes Thema

Ralf9

Zitat von: Wzut am 18 Oktober 2023, 19:26:32Ich 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 :
Modulation 2-FSK
Center frequency 868.3Mhz
Frequence deviation 19Khz
Datarate 10Kbit
Preamble: 4 bytes (1010...)
Syncword: 0xc626c626
 

Zitat von: Ralf9 am 18 Oktober 2023, 19:41:58Im 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.

Zitat von: Ralf9 am 18 Oktober 2023, 20:17:43Laut
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

Zitat von: Wzut am 30 Oktober 2023, 09:05:59Thema 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.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Ich habs mal mit Homematic getestet, damit konnte ich was empfangen
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
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:
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
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
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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Wzut

Das macht doch schon mal Hoffnung auf mehr  8) , THX
Der Duino ist bestellt und sowie er bei mir ist lege ich los und melde mich wieder.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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 :
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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?
  } 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;
    }
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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

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 ???
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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 :
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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Wzut

1. Das ist schon deine Version :
# $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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Ralf9

Dies ist nicht die aktuelle Version.
Die aktuelle ist
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:
Zitat/* 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.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Wzut

Zitat von: Ralf9 am 03 November 2023, 19:02:29Dies 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. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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 :
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 :
# 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 ? 
 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Ralf9

ZitatAllerdings 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:
} 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:
length_min      => '24',     # 12 Byte
Zitat# 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.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7