SIGNALDuino Empfänger Firmware V 3.3.2r-dev

Ralf9 · 10 August 2018, 12:09:29

Da kann ich leider auch nicht weiterhelfen, da ich keinen radino zum Testen habe.
Evtl bist Du der erste der dies mit einem radino versucht hat.

Gruß Ralf

l2r · 10 August 2018, 13:45:59

ok, alles klar.

ich komm ja erstmal zurecht.

Vielen Dank schon mal und ein schönes Wochenende!

Gruß Michael

moonsorrox · 14 August 2018, 17:46:01

ich frage hier auch mal, denn ich habe einen Thread eröffnet und dort meine Probleme geschildert.
Kann sein das mir evtl. eine Aktualisierung der Firmware weiterhilft..? Oder eben nicht dann hat sich da hier erledigt. Sduino habe ich erst vor einer Woche bei ebay gekauft.

Ralf9 · 14 August 2018, 18:01:35

dies kannst Du nur durch testen mit der Firmware rausfinden.

Gruß Ralf

Ralf9 · 31 August 2018, 20:47:57

Hier ist ein Ausblick auf die nächste Version V 3.3.2.1-rc0 (ist rc0 ok, oder ist es besser, wenn ich mit rc3 weiter zähle?

Momentan können mit einer MU-Nachricht maximal 255 Pulse übertagen werden. Ein Überlauf wird mit einem O am Ende gekennzeichnet.
In der 3.2.2 habe ich zwar eine Erkennung von Wiederholungen bei MU-Nachrichten eingebaut, diese funktioniert aber nicht bei allen MU-Nachrichten.
Nun werden bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen.
Die Nachrichten müssen dann in der 00_SIGNALduino.pm wieder zusammengesetzt werden.

Das CP=xx und R=xx wird nun vor den Daten ausgegeben.

Code Auswählen

MU;P0=-500;P1=503;P2=-1057;P3=1425;P4=-25402;CP=1;D=012121212121232121212121212121212121232323232321232123212321232323232323232323232323232323232323232323232323232321212121232141212121212121212321212121212121212121212323232323212321232123212323232323232323232323232323232323232323232323232323212121212321;O0;
MO;D=41212121212121212321212121212121212121212323232323212321232123212323232323232323232323232323232323232323232323232323212121212321;e;

Damit die MU-Nachrichten nun noch verarbeitet werden können, ist in der "SIGNALduino_Parse" eine Anpassung notwendig. Es muß in der folgenden Abfrage das CP=\d; entfernt werden:

Code Auswählen

elsif (@{$hash->{muIdList}} && $rmsg=~ m/^MU;(P\d=-?\d+;){3,8}D=\d+;CP=\d;/)

Damit auch die MO-Nachrichten verarbeitet werden können sind noch weitere Anpassungen in der 00_SIGNALduino.pm notwendig.

Gruß Ralf

Ralf9 · 02 September 2018, 14:59:49

Ich habe in der Firmware noch einen Bug gefunden, der für mich sehr schwierig zu finden war.
Wenn die Bedingung "if (message == pattern_pos)" nie erfüllt ist, dann ergibt das folgende "for" eine Endlosschleife.
Mir ist nicht klar warum durch das "i >= 0" die for Schleife nicht bei 0 endet. Sie macht weiter mit 255.
Mit "i>0" endet die Scheife bei 1

Code Auswählen

if (messageLen > 0) {
	for (uint8_t i = messageLen - 1; i >= 0 && histo[pattern_pos] > 0; --i)
	{
		if (message[i] == pattern_pos) // Finde den letzten Verweis im Array auf den Index der gleich ueberschrieben wird
		{
			i++; // i um eins erhoehen, damit zukuenftigen Berechnungen darauf aufbauen koennen
			bufferMove(i);
			calcHisto();
			break;
		}
	}
}

Ich habe es ein wenig umgeschrieben, dies sollte eigentlich das gleiche machen.

Code Auswählen

if (messageLen > 0 && histo[pattern_pos] == 0) {
	for (uint8_t i = messageLen; i > 0; --i)
	{
		if (message[i-1] == pattern_pos) // Finde den letzten Verweis im Array auf den Index der gleich ueberschrieben wird
		{
			bufferMove(i);  // i um eins erhoehen, damit zukuenftigen Berechnungen darauf aufbauen koennen
			calcHisto();
			break;
		}
	}
}

Gruß Ralf

RappaSan · 03 September 2018, 08:44:06

Mit i >= 0 ist 0 ebenso wahr wie alle zahlen > 0.
uint8_t heißt doch bestimmt unsigned Integer 8 Bit, oder? Dann kann der Wert nur zwischen 0 und 255 liegen und nicht negativ werden.

Ralf9 · 15 September 2018, 22:21:53

ZitatDann kann der Wert nur zwischen 0 und 255 liegen und nicht negativ werden.

Danke, nun ist mir auch klar geworden, daß die Abfrage i >= 0 nur funktionieren kann, wenn i auch negativ werden kann.

Gruß Ralf

Ralf9 · 15 September 2018, 23:04:43

ZitatHier ist ein Ausblick auf die nächste Version V 3.3.2.1

Momentan können mit einer MU-Nachricht maximal 255 Pulse übertagen werden. Ein Überlauf wird mit einem O am Ende gekennzeichnet.
In der 3.2.2 habe ich zwar eine Erkennung von Wiederholungen bei MU-Nachrichten eingebaut, diese funktioniert aber nicht bei allen MU-Nachrichten.
Nun werden bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen.
Die Nachrichten müssen dann in der 00_SIGNALduino.pm wieder zusammengesetzt werden.

Die neue Option, daß bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen werden, ist default mässig abgeschaltet.

ein: (bei get config steht dann: MuNoOverflow=1

Code Auswählen

get sduino raw CEO

aus:

Code Auswählen

get sduino raw CDO

Da bei MU-Nachrichten die Wiederholungen nun in der 00_SIGNALduino.pm verarbeitet werden können, kann in der Firmware die Erkennung und spliten von Wiederholungen abgeschaltet werden:

Code Auswählen

get sduino raw CSmuthresh=0

Da dies noch im beta Stadium ist und das zusammensetzen der Nachrichten noch nicht in der offiziellen 00_SIGNALduino.pm ist, ist zum Testen eine angepasste 00_SIGNALduino.pm notwendig:
https://github.com/Ralf9/RFFHEM/blob/master/FHEM/00_SIGNALduino.pm
und hier als raw für den download:
https://raw.githubusercontent.com/Ralf9/RFFHEM/master/FHEM/00_SIGNALduino.pm

Gruß Ralf

Ralf9 · 29 September 2018, 10:13:36

History:

11.05.18 V 3.3.2-rc1
- FIFO_LENGTH von 100 auf 120 erhöht
- Bei getSync() das syncLenMax von 100 auf 120 erhöht. Dies ist zum Empfangen von Homeeasy HE_EU notwendig
- "get sduino uptime" Fehler behoben (nun funktioniert auch größer 49 Tage).

11.06.18 es gibt für den cc1101 eine neue Version 3.3.2-rc2
- Bei send raw mit dem Parameter "F=..." (Frequenz) konnte es Probleme geben.

15.09.18 V 3.3.2.1-rc3
-Da nun bei den MU-Nachrichten das CP=x und R=xx vor den Daten ausgegeben wird, funktioniert diese Version nicht mehr mit der 00_SIGNALduino.pm aus dem normalen fhem update. Es wird die Entwicklerversion dev-r33 benötigt.
- Ich habe den FIFO Empfangspuffer auf 130 erhöht
- Die max Länge der Sendekommandos habe ich beim nano mit cc1101 auf 350 und beim nano ohne cc1101 auf 400 erhöht.

29.09.18 V 3.3.2.1-rc4
- Es waren bei der Übertragung von komprimierten (bei get config steht Mred=1) Nachrichten 2 Fehler:
Bei komprimierten MS-Nachrichten konnte am Anfang ein Bit zuviel sein.
Bei komprimierten MU-Nachrichten war am Ende ein Bit zuwenig oder ein Bit zuviel.
Z.B. bei der ID 34 (QUIGG GT-7000 Funk-Steckdosendimmer) hat dadurch am Ende ein Bit gefehlt.
- ~~Es gibt eine neue Option mit der bei einem Überlauf die restlichen Daten in MO-Nachrichten übertragen werden.~~
Wurde in der V 3.3.2.1-rc6 anders gelöst.

03.11.18 V 3.3.2.1-rc5
- mit "set sduino raw CDL" wird nun auch beim Senden die Message-LED ausgeschaltet.
- Ich habe die Syntaxprüfung beim Senden erweitert, wenn beim Sendebefehl der Datenteil fehlt, wird "send failed" ausgegeben.
- Zum kompilieren habe ich nun die z.Zt. aktuelle Arduino IDE 1.8.7 verwendet.

miniCUL:

Code Auswählen

set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_miniCUL_3321rc5.hex

02.12.18 V 3.3.2.1-rc6
- Bei get config wird nun auch hinter dem / die FIFO Größe ausgegeben (MdebFifoLimit=120/140).
- Ich habe den FIFO auf 140 erhöht.
- Ich habe die Ausgabe von sehr langen MU-Nachrichten überarbeitet. Bei einem Überlauf werden die restlichen Daten nicht mehr in MO-Nachrichten übertragen.
Nach einem Überlauf bei einer MU-Nachricht werden die restlichen Daten an die MU-Nachricht angehängt.
Die Ausgabe der sehr langen MU-Nachrichten funktioniert z.T. bei der offiziellen Entwicklerversion dev-r33 nur bei unkomprimierte Nachrichten (Mred=0).

Bei komprimierten Nachrichten ist noch eine Anpassung in der 00_signalduino.pm erforderlich
https://github.com/RFD-FHEM/RFFHEM/commit/7cd526edcf43684d27b631243262a59a9a374f85
https://github.com/Ralf9/RFFHEM/issues/2

nano mit cc1101:

Code Auswählen

set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nanoCC1101_3321rc6.hex

3.3V promini mit CC1101

Code Auswählen

set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_3v3prominiCC1101_3321rc6.hex

Diese Version ist für diejenigen, die mit einem 3.3V promini und der nanocul Verkabelung einen Signalduino gebaut haben.

nano ohne cc1101:

Code Auswählen

set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_nano_3321rc6.hex

radino:

Code Auswählen

set sduino flash https://raw.githubusercontent.com/Ralf9/SIGNALDuino/dev-r332_cc1101/firmware/SIGNALduino_radinoCC1101_3321rc6.hex

9.12.18 V 3.3.2.1-rc7
- Optimierungen damit weniger RAM belegt wird.

12.01.19 V 3.3.2.1-rc8
- Es werden nun auch die sehr langen MC-Nachrichten der neuen Oregon V3 Sensoren unterstützt.
- der Windmesser W132 von der Wetterstation Ventus W155 wird nun auch sauber empfangen
Bei MS-Nachrichten wird nun geschaut ob nach dem sync innerhalb der nächsten 10 Einträge weitere sync folgen und diese ggf übersprungen. Bei nicht komprimierten MS-Nachrichten wird dann mit "s<anz> die Anzahl ausgegeben.

16.06.19 V 3.3.2.1-rc9
Es werden nun am Anfang von MS-Nachrichten auch mehrere sync in Folge erkannt und übersprungen.
Z.B. ein Temperatursensor der ID 33 hat am Anfang 14 sync.
Bei der Ausgabe werden nun mit "b" die Position des ersten Sync und mit "s" die Anzahl der sync ausgegeben.
Z.B.: "...01010;CP=1;SP=3;R=6;O;b63;s4;m0;" beim GT-WT-02 Temperatursensor

Gruß Ralf

Markus. · 01 Oktober 2018, 05:47:49

Zitat von: Ralf9 am 29 September 2018, 10:13:36
Diese Version funktioniert nicht mehr mit der 00_SIGNALduino.pm aus dem normalen fhem update. Es wird die Entwicklerversion dev-r33 benötigt.
Bei der 00_SIGNALduino.pm aus dem normalen fhem update ist eine kleine Anpassung notwendig, bei Bedarf kann ich diese hier posten.

Hallo Ralf,
wann kann man denn damit rechnen, das die geänderte 00_SIGNALDUINO.pm ins "normale" fhem update übernommen wird.
Hintergrund ist das ich zwei SignalESPs an FHEM habe, einen 433 für IT der produktiv eingestzt wird und soweit funktioniert und einen 868 der für Testzwecke missbraucht wird. Würde gerne beide parallel betreiben. Gibt's da eine Möglichkeit das zu trennen damit ich den 868 auf RC4 laufen lassen kann?
Der 433er läuft zur Zeit mit Firmware Version V 3.3.1-dev SIGNALESP cc1101 433MHz - compiled at Nov 2 2017 ausschliesslich für IT Sachen.

Viele Grüße

Markus

Ralf9 · 01 Oktober 2018, 17:30:34

Hallo Markus,

die geänderte 00_SIGNALDUINO.pm wird nur für die Firmware Version V 3.3.2.1 benötigt.
Für die SignalESPs ist die geänderte 00_SIGNALDUINO.pm nicht nowendig, da es von meiner V 3.3.2.x keine firmware für die SignalESPs gibt.

Gruß Ralf

sash.sc · 01 Oktober 2018, 17:37:40

Alles ein wenig verwirrend!
[emoji33][emoji6]

Gesendet von meinem E6653 mit Tapatalk

Markus. · 01 Oktober 2018, 20:02:26

Hallo Ralf,

ich habe mich auch nicht richtig ausgedrückt....sorry....

Also ich habe einen SignalESP 433Mhz und einen Signalduino 868 MHZ (natürlich seriell)
Beide verwenden ja die selbe Signalduino.pm
Wie kann ich das denn handhaben in Bezug auf Tests mit dem seriellen Signalduino und deiner Firmware?

Gruß

Markus

Ralf9 · 02 Oktober 2018, 22:25:47

ZitatWie kann ich das denn handhaben in Bezug auf Tests mit dem seriellen Signalduino und deiner Firmware?

Wenn Du die V 3.3.2.1-rc4 und die 00_SIGNALDUINO vom normalen fhem update benutzen möchstest, dann mußt Du in der 00_SIGNALDUINO die folgende Zeile ändern.

In der sub SIGNALduino_Parse($$$$@) die Zeile 3802

Code Auswählen

elsif (@{$hash->{muIdList}} && $rmsg=~ m/^MU;(P\d=-?\d+;){3,8}D=\d+;CP=\d;/)
abändern in

Code Auswählen

elsif (@{$hash->{muIdList}} && $rmsg=~ m/^MU;(P\d=-?\d+;){3,8}((CP|R)=\d+;){0,2}D=\d+;/)

danach fhem neustarten
oder ein
reload 00_SIGNALduino.pm

Gruß Ralf