Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

[Ralf9]

siehe hier
https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921

WS3D:
3D  No operation. May be used to get access to the chip status byte.

XE -> enableReceiver

Dies ergibt dann

Code Auswählen Erweitern

MN;D=9166066A46382351E06891C4;N=2;R=91;
in fhem:

Code Auswählen Erweitern

2020.04.29 21:59:32.440 4 : sduinoD/msg get raw: MN;D=9166066A46382351E06891C4;N=2;R=91;
2020.04.29 21:59:32.440 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 103 -> Lacrosse mode 2
2020.04.29 21:59:32.440 4 : sduinoD LaCrosse_convert: ID=103, addr=5 temp=20.6 channel=1 nohum=106 bat=0 batInserted=128
2020.04.29 21:59:32.440 4 : sduinoD ParseMN: ID=103 dmsg=OK 9 5 129 4 182 106
2020.04.29 21:59:32.441 4 : sduinoD Dispatch: OK 9 5 129 4 182 106, -28.5 dB, dispatch
2020.04.29 21:59:32.476 3 : LaCrosse: Unknown device 05, please define it

Mit einem

Code Auswählen Erweitern

set LaCrossePairForSec 30
wird dann das LaCrosse device angelegt

[killah78]

Sieht gut aus. Baue das morgen mal in meine FHEM Testumgebung ein.
Erstmal danke.

[juergs]

Hallo Zusammen,

ich habe jetzt einen funktionierenden Prototyp für eine WLAN-SERIAL-BRIDGE zum Maple-Signalduino in Micropython realisiert.
Allerdings muss jetzt noch ausgiebig getestet werden, um ggf. den Ablauf ggf. noch verfeinern.

Die Parametrierung + Programmierung ist über einen seriellen Adapter (FTDI) relativ einfach.
Sie könnte aber auch über USB an den UART_1 des Maples, in einer Art "Programmiermodus", durchgeschleift werden.

Eine Eigenart der W600-Implementierung des Sockets ist, dass die recv-Methode "blocking" ist und die Übertragung auf
eine Anfrage/Telegramm von FHEM wartet.  (Ggf. könnte man das im Modul als Attribut berücksichtigen?)
Non-Blocking habe bisher noch nicht hinbekommen, da die Methode socket.socket_setblocking(0) nicht in diese MP-Version übernommen
bzw. implementiert wurde. (Falls dazu jemand eine Lösungs-Idee hat...  )
Leider ist der IST-Zustand von MP und der der Doku leider doch etwas unterschiedlich ...
Die ESP8266/ESP32-Plattform scheint da besser "ausgrüstet" zu sein ...
Der W600 scheint mir aber schon wegen der Größe vorteilhaft zu sein.

Im Moment habe ich die Variante mit dem Managen von mehreren Client-Verbindungen gespart und lasse nur eine TCP-Connection zu.
Das sollte im Normalfall reichen ... 

Jetzt baue ich mir noch ein Testsystem dazu auf und probiere das Ganze mit FHEM aus ...

Grüße,
Jürgen

/Edit:  durch die Verwendung von Micropython wäre der Code ebenfalls portabel zur ESP8266/ESP32-Hardware !

/Edit2: HowTo auf meiner Github-Wiki-Seite.

[killah78]

Hi, wie angekündigt, habe ich den mapleduino heute mal in mein FHEMtest angebunden.
Funktionierte auch wie angedacht.
Allerdings ist mir dann folgendes aufgefallen: Nach einigen empfangenen Meldungen hört der Empfang auf! generell bekomme ich weiterhin Antworten und kann zB. Version abfragen. Ich empfange erst weitere Meldungen wenn ich erneut ein "XE" sende.
Als Test habe ich hier mein TX35-IT liegen, Signalstärke sollte also auch nicht das Problem sein.

Hat das schonmal jemand so beobachten können?
Stromverbrauch habe ich derzeit mit einem Stamp ca 0.04A bei 5.10V. Sollte also nicht das Problem sein.

Gruss

[juergs]

Wenn der Sensor zu nah am Signalduino liegt?

[killah78]

Wenn der Sensor zu nah am Signalduino liegt?

Nein, derzeit 10 Meter Entfernung. Hatte ich auch probiert.
Wie gesagt, Empfang hört auf und kann dann mit XE wieder für eine kurze Zeit gestartet werden.
Teilweise werden 20 Nachrichten hintereinander Empfangen, manchmal nur 2.
Abstand der Nachrichten sind denke ich 10 Sekunden.

[juergs]

Hm, wenn mit XE, dann kam vorher ein XQ (receive disable) ?

Wie sieht  das Log auf verbose 5 aus?

Abstand der Nachrichten sind denke ich 10 Sekunden

Auf 868 MHz?

[killah78]

Ich habe jetzt vorerst wieder aus dem FHEM rausgenommen und beobachte per Serial-Monitor.
Ein  XQ kam von mir nicht. In der Ausgabe selbst sehe ich auch nichts.
Ein Debugport mit weiteren Meldungen gib es nicht?
Phänomen ist an mehreren Rechnern, sowohl Intel/Windows, als auch ARM/Linux.

Ich habe jetzt meinen mapleCUL, den ich mir Zeitgleich aufbaue mal in mein FHEMtest eingebunden, ob der stabil läuft, Das wäre dann die selbe (Hardware-)charge vom Maple Mini und den Stamps.
Aber der läuft bisher sehr stabil, jedoch SlowRF, nicht Lacrosse.

Das Log im FHEM hatte übrigens im verbose 5 nichts interessantes vermeldet. Habe ich aber jetzt verworfen, und wie gesagt derzeit nur am SerialMonitor.

Edit: Ja 868MhZ, Lacrosse Mode2. Ist ein TX35-IT Temperatursensor mit neuen Batterien.
Nochmal Edit: aha. Sendebeschränkung? Gibt es da auch eine Prüfung irgendwo?

[juergs]

Edit: aha. Sendebeschränkung? Gibt es da auch eine Prüfung irgendwo?

Ja genau! Eigenlich nur alle 6 Minuten  (10% pro Stunde-Regel), wenn ich mich recht erinnere ...

Du kannst den Mapl-Signalduino auch nur per Serial  (Bitrate 115200,8,n,1)  steuern.

"V"
"XQ"
"XE"
immer CR oder CR/LF ...

dann sollten die empfangenen Funkpakete im Terminal kommen.
Sollte dann irgendwann mal nichts mehr kommen,  liegt es  an....   

[Ralf9]

Die 10% pro Stunde-Regel gibts nur beim Senden, Du empfängst ja nur.

Wenn der Empfang auch im Terminal aufhört dann gib mal folgendes ein:

Code Auswählen Erweitern

bA
Antw: switch to radio A

und dann:
V
WS3D
br

[killah78]

Hmmh. Also im Moment verstehe ich es nicht. Im Moment funktioniert es.
Ich hatte den Stick längere Zeit nicht angeschlossen. Jetzt wieder angeschlossen und er empfängt ohne Probleme.
Das einzige was mir aufgefallen ist, dass wenn ich ein "C99" mache, ist alles mit "FF" gefüllt.
Erst mit einem bA1 erscheint das wieder korrekt. Aber trotzdem wird empfangen.
Ich lasse das jetzt mal so laufen und beobachte, ob er wieder irgendwann aufhört.

[Ralf9]

Das Problem dabei ist, daß ich diesen Fall, daß jemand nur den ersten cc1101 (Radio A) verwendet, bis jetzt noch nicht berücksichtigt habe.
Per default ist normalerweise Radio B selektiert, bei Version ist hinter B ein *

Deshalb fehlt bei Version der *
(R: A1)

Nach einem "bA" (switch to radio A) ist dann Radio A selektiert, in Version steht dann
(R: A1*)


Ich muß da noch eine Abfrage einbauen, daß wenn es Radio B nicht, gibt  daß dann Radio A per default selektiert ist.
Oder muss ich auch damit rechnen, daß jemand nur das dritte cc1101 (Radio C) verwendet.

Das einzige was mir aufgefallen ist, dass wenn ich ein "C99" mache, ist alles mit "FF" gefüllt.

Die Register abfragen werden immer auf das selektierte Radio gemacht, da hier das nicht vorhandene Radio B selektiert ist, kommt FF zurück   

[killah78]

Also er stoppt wieder. Es sind allerdings deutlich mehr Nachrichten empfangen worden.
Trotzdem stoppt er.
Das stimmt, wenn ich starte ist A1 ohne Sternchen, also nicht selektiert.
Ich starte nochmal neu und selektiere zu Anfang direkt mal Radio A.
Mal sehen ob es eine Änderung bringt.

Edit: Stoppt trotzdem.
ich habe zuerst Radio A selektiert. Dann sind 13 Nachrichten gekommen. Dann habe ich 5 Minuten gewartet, ein V und ein XE gemacht und es kamen weitere Nachrichten.

Code Auswählen Erweitern

MN;D=97C6136AFA35E7AFF1E5EFFE;N=2;R=236;
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1) - compiled at Apr 29 2020 00:29:05
switch to radio A
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
MN;D=97C6136AFAFB9EF4F75D3C73;N=2;R=230;
MN;D=97C6136AFACFBF966CD5410D;N=2;R=241;
MN;D=97C6136AFAAF457E5D937F53;N=2;R=243;
MN;D=97C6136AFAEE7F5B68BDDF1F;N=2;R=237;
MN;D=97C6136AFA1D779DFDEA7EC5;N=2;R=234;
MN;D=97C6146A54FA55D77B34F8FF;N=2;R=231;
MN;D=97C6146A54CBF832F77F7B8F;N=2;R=222;
MN;D=97C6146A543DDD7A17EFF9FD;N=2;R=237;
MN;D=97C6146A54B7F767D07CAFB9;N=2;R=242;
MN;D=97C6146A54ED779E6BFF52B3;N=2;R=242;
MN;D=97C6146A54FB775FAEFEAC5F;N=2;R=243;
MN;D=97C6146A547DF3C90754FE9D;N=2;R=240;
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
rxA=1
MN;D=97C6136AFA3FF3F77DFAEFFC;N=2;R=244;
MN;D=97C6136AFA3FCFDF75FDCFD6;N=2;R=246;
MN;D=97C6136AFA75EEE5F3ED1E3B;N=2;R=246;
MN;D=51113D05471500FBFEDB35DE;N=2;R=221;
MN;D=97C6136AFAEB9FED799F51E5;N=2;R=245;

Anschließend kamen nur noch 7 Nachrichten bis zum erneuten Stop.... und danach nur 9 Nachrichten.

Komisch finde ich, dass ich vorhin als ich den Signalduino nach langem Ausstöpseln lange betreiben konnte, bzw er mehrere Hundert Nachrichten empfangen hat. Und jetzt wieder nur einige wenige.

zur Vervollständigung:
Als Antwort auf bA, V, WS3D, br:

Code Auswählen Erweitern

switch to radio A
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
cmdStrobeReg 3D chipStatus 1 delay2 1
r=A b=1 N=2 ccmode=3 sync=2DD4 ccconf=21656A88820622F856070018166C436891 boffs=0100

[Ralf9]

Bitte mach mal, wenn er stoppt:

WS3D

C35

br

V

[killah78]

Code Auswählen Erweitern

cmdStrobeReg 3D chipStatus 1 delay2 1
C35 = 0D
r=A b=1 N=2 ccmode=3 sync=2DD4 ccconf=21656A88820622F856070018166C436891 boffs=0100
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05

Läuft danach aber nicht wieder an. Erst mit einem XE.