DMSG stimmt eventuell nicht about signalduino_tool HOT 25 CLOSED

Ralf hat sich entschieden das Symbol F nach 11 zu konvertieren.

Dieses F ist das float der Protokolldefinition
float => [1,-1],
Beim Senden der Gruppentaste muss dieses float auch wieder gesendet werden.

Bei den pt2272 gibt es die 3 Zustände:

  "00" => "0",
  "01" => "F",
  "11" => "1"

Bei den orginal intertechno gibt es nur 0 und F.
Da bei dem ITS-150 der Zustand 1 (11) nicht vorkommen kann, verwende ich das 1 für das float

Wenn das Senden der Gruppentaste funktionieren soll, muss das F nach 11 gewandelt werden, oder habe ich was übersehen?

Oder ist das kompatibel zum Cul wichtiger als das Senden der Gruppentaste?

from signalduino_tool.

kann es sein das die ITR-1500 das selbige Protokoll nutzen

Nach der Beschreibung ist die ITR-1500 selbstlernend und benutzt das ITV3 Protokoll

from signalduino_tool.

Dies hängt damit zusammen:
https://forum.fhem.de/index.php/topic,58397.msg758574.html#msg758574

Die Gruppentaste der ITS-150 ist was ganz spezielles

from signalduino_tool.

Hi Ralf,

Die Anpassung F zu 01 ist in dem Commit von damals enthalten.
Damit ist es zum CUL kompatibel.

Wenn wir F zu 11 wandeln würde, dann hat das doch Auswirkung auf alle Definitionen die ein F haben, oder habe ich etwas übersehen?
Oder wird das Protokoll 3.1 nur für die Gruppentaste verwendet und wir könnten es darauf reduzieren?

from signalduino_tool.

Ich denke , ich werde daheim heute Abend mal einen neuen Faden eröffnen wo wir die Problematik angehen könnten und separat als Thema Kapseln.

Dies stellt die Weichen, wenn wir alle wollen und uns zusammenfassen / zusammenreißen, wir die möglich anpacken 2 Ergebnisse der verschieden Versionen beleuchten.

Es wäre sehr schön und zielstrebig, wenn wir so nur 1 Ergebnis für beide FW Versionen haben. Das kommt uns allen Zu gute. @sidey79 und @Ralf9 wäre es in eurem Sinne?

from signalduino_tool.

@HomeAutoUser
Die nicht stimmenden dmsg haben nichts mit der firmware zu tun.

a) Die DMSG in der JSON Datei ist falsch
b) Das Modul arbeitet nicht korrekt

@sidey79
hast Du beachtet, daß die dmsg in der JSON immer die dmsg vom ersten dispatch ist?

from signalduino_tool.

Oder wird das Protokoll 3.1 nur für die Gruppentaste verwendet und wir könnten es darauf reduzieren?

Das Protokoll 3.1 wird von der ITS-150 von Stefan# verwendet, um festzustellen ob andere ITS-150 mit anderen Empfängern auch das Protokoll 3.1 verwenden, bräuchten wir auch von anderen ITS-150 MS-Nachrichten.

Das F für float wird nur von der Gruppentaste des ITS-150 verwendet.

Wenn wir F zu 01 (F) wandeln, ist es zwar zum CUL kompatibel, aber die Gruppentaste kann nicht gesendet werden.

Wenn wir F zu 11 (1) wandeln, dann müsste ein senden der Gruppentaste möglich sein.
Das 1 kann dann beim sendMsg nach 0D gewandelt werden

sub SIGNALduino_ITV1_31_tristateToBit($)	# ID 3.1
{
	my ($msg) = @_;
	# Convert 0 -> 00   1 -> 0D F => 01 to be compatible with IT Module
	$msg =~ s/0/00/g;
	$msg =~ s/1/0D/g;
	$msg =~ s/F/01/g;
		
	return (1,$msg);
}

In der Anleitung steht folgendes
https://www.funkschalter-intertechno.de/mediafiles/Sonstiges/manual-ITS-150.pdf

Die  Gruppenschaltung  ist  jedoch  nur  bei
den  Typen  ITS-150  bzw.   ITR-3500    und
ITR-300 möglich

from signalduino_tool.

@HomeAutoUser
Die nicht stimmenden dmsg haben nichts mit der firmware zu tun.

Ich meine dann eher die Verarbeitung in der SIGNALduino.pm @Ralf9.

@Ralf9 Dort wo aber die RAWMSG 2 unterschiedliche Ergebnisse (Modul hat jeweils den selben Stand.) bringt, einmal bei dir i45FF15 und bei @sidey79 seiner Variante i455515 ist es doch die SIGNALduino.pm, WENN ich ein und die selbe RAWMSG dispatche, ODER wie erklärst du dir das?

@sidey79

In der JSON Datei wird allerdings
dmsg":"i45FF15", erwartet.

2019.06.10 19:19:39 4: sduino_dummy/msg get raw: �MS;P1=309;P2=-1130;P3=1011;P4=-429;P5=-11466;D=15123412121234123412141214121412141212123412341234;CP=1;SP=5;R=38;�
> 2019.06.10 19:19:39 4: sduino_dummy: Matched MS Protocol id 3.1 -> itv1_sync40
> 2019.06.10 19:19:40 4: sduino_dummy: Decoded matched MS Protocol id 3.1 dmsg i455515 length 24  RSSI = -55

kommt auch bei DIR raus aber nicht bei @Ralf9

2019.06.10 17:19:30 4: sduino_dummy/msg get raw: �MS;P1=309;P2=-1130;P3=1011;P4=-429;P5=-11466;D=15123412121234123412141214121412141212123412341234;CP=1;SP=5;R=38;�
2019.06.10 17:19:30 4: sduino_dummy: Matched MS Protocol id 3.1 -> itv1_sync40, bitLen=24
2019.06.10 17:19:30 4: sduino_dummy: Decoded MS Protocol id 3.1 dmsg i45FF15 length 24 RSSI = -55

Genau solche Unterschiede gibt es auch noch bei anderen Protokollen welche ich notiert habe. Das meine ich mit Gleichheit schaffen und anpassen.

from signalduino_tool.

@HomeAutoUser

Ralf hat sich entschieden das Symbol F nach 11 zu konvertieren.

Bei der Normalen Version wird F seit jeher zu 01 konvertiert. (CUL kompatibel)
Warum beim Senden nicht das richtige Signal generiert werden kann verstehe ich nicht nicht.
Der Zustand F kann meiner Meinung nach aber bei allen pt2272 basierenden Dosen vorkommen.

Dieser ganze Triste kram sorgt immer wieder für Rätsel.

from signalduino_tool.

Ralf hat sich entschieden das Symbol F nach 11 zu konvertieren.

Dann erklärt mir bitte einer mal wieso bei deiner Version i455515 herauskommt und bei Ralf9 i45FF15 herauskommt. da stehe ich auf dem Schlauch ODER nutzt er das F nur zur "richtigen" Erkennung?
Da ergibt sich dann meine Frage, wieso klappt es nicht beim senden oder wieso wählte man den Weg?

UNABHÄNGIG davon, dann gibt es auch das Problem bei

ID 9 - RAWMSG

MU;P0=2120;P1=-5736;P2=496;P3=-1024;P4=1467;CP=4;R=16;D=0123232323234323434343232323234343434343232343232323234323432343434323434343434343434343434343434343434343434343432323434323432343432343234343434343434343432343234343432;e;

Dein Ergebnis P9#FA3C1BD4400000CA50050
Ergebnis Ralf P9#FA3C1BD4400000CA50051

Dort wird nichts Konvertiert....

from signalduino_tool.

Ergebnis Ralf P9#FA3C1BD4400000CA50051

Die 1 am Ende kommt durch das reconstructBit, siehe
https://forum.fhem.de/index.php/topic,67587.msg947567.html#msg947567

from signalduino_tool.

float => [1,-1],
Beim Senden der Gruppentaste muss dieses float auch wieder gesendet werden.
Bei den pt2272 gibt es die 3 Zustände:

  "00" => "0",
  "01" => "F",
  "11" => "1"

Die Festlegung der Werte float => [1,-1], Passen leider nicht zum Datenblatt:

Und das Signal, passt dann nicht zum PT2262 Datenblatt.

Bei den orginal intertechno gibt es nur 0 und F.

Da bei dem ITS-150 der Zustand 1 (11) nicht vorkommen kann, verwende ich das 1 für das float
Das war halt so eine Frage ob das Protokoll 3.1 erkennt dass es eine ITS-150 ist.

Oder ist das kompatibel zum Cul wichtiger als das Senden der Gruppentaste?
Es wäre toll, wenn das Modul zum Wiki passt finde ich.
https://wiki.fhem.de/wiki/Intertechno_Code_Berechnung

from signalduino_tool.

Danke für die Erläuterung @Ralf9.

Die 1 am Ende kommt durch das reconstructBit, siehe

Habe ich das deiner Version entnommen, das du das reconstructBit automatisch setzt?

@sidey79 #8 (comment) hier wäre dann das reconstructBit notwendig.

from signalduino_tool.

Und das Signal, passt dann nicht zum PT2262 Datenblatt.

Dann ist in der ITS-150 kein PT2262 enthalten.

Dies wird bei der Gruppentaste empfangen:
MS;P1=309;P2=-1130;P3=1011;P4=-429;P5=-11466;D=15123412121234123412141214121412141212123412341234;CP=1;SP=5;R=38;
hier ist
34 one
12 zero
14 float

from signalduino_tool.

Da wir das Senden der Gruppentaste mangels passenden Empfängern (ITR-3500 oder ITR-300) momentan sowieso nicht testen können, können wir es auch vorerst kompatibel zum CUL lassen.
Ich ändere es dann bei mir ab (F zu 01 (F) )

from signalduino_tool.

@ralf, kann es sein das die ITR-1500 das selbige Protokoll nutzen? Sowas besitze ich und könnte ich vermessen

from signalduino_tool.

@HomeAutoUser
Wir haben hier nun mehrere Optionen des angleichens betrachtet.

Was mir aber insgesamt unklar ist, woher kommt der Referenzwert DMSG. An diesem Beispiel ist zu erkennen, dass das SIGNALduino Modul noch nie den besagten Referenzwert ausgegeben hat.

from signalduino_tool.

Was mir aber insgesamt unklar ist, woher kommt der Referenzwert DMSG. An diesem Beispiel ist zu erkennen, dass das SIGNALduino Modul noch nie den besagten Referenzwert ausgegeben hat.

Meinst du den „Ort“ der DMSG woher diese Stammt oder wie meinst du das, „unklar ist, woher kommt der unklar ist, woher kommt der Referenzwert„?

SIGNALDUINO Referenzwert, da können wir / du nur schauen den Fehler einzugrenzen wenn es einer ist.

from signalduino_tool.

Ich habe auf Basis der rmsg und dmsg ein Testscript erstellt.

Der Wert aus dmsg wird als Sollwert verwendet und das Ergebnis aus dem SIGNALduino_dispatch wird als istwert
verwendet.
Weicht das Ergebnis ab, dann wird es als Fehler interpretiert.

An diesem Beispiel haben wir nun gelernt, dass der Sollwert noch nie durch das SIGNALduino Modul erzeugt wurde.
Jetzt stellt sich mir die Frage, woher diese Sollwerte überhaupt kommen und ob man diese überhaupt als Sollwert ansehen kann.
Ich hatte irgendwie erwartet, dass in dmsg nur Werte auftauchen, die das Modul auch schon mal erzeugt hat.

from signalduino_tool.

Ich hatte irgendwie erwartet, dass in dmsg nur Werte auftauchen, die das Modul auch schon mal erzeugt hat.

Das ist der Fall was ich von meinen Ergänzungen sagen kann.

Meiner Tests haben auch gezeigt, das bei manchen RAWMSG bisher ein falsches Ergebnis heraus kommt, weil angenommen das ReconsBit bei uns nicht gesetzt ist aber bei Ralf seiner Version genutzt wird. Das erklärt auch, wenn eine DMSG heraus kommt die „vermeintlich“ als Fehler Implementiert wird. Derzeit handelt es sich ca. Um 4 oder 5 Protokolle wo dies der Fall ist. Genau da, müsste man schauen ob die RAWMSG falsch ist oder wirklich nur mit ReconsBit zum richtigen Ergebnis führt.

from signalduino_tool.

Das festlegen was falsch oder richtig ist, fällt mir in diesem Fall schwer.

Ich hatte angenommen, dass die DMSG Werte aus dem SIGNALduino Modul stammen.
Wenn die Werte aus forks stammen, dann ist das ja kein Wunder, dass es Abweichungen gibt.

Richtig oder falsch stellt sich mir erst einmal noch nicht, sondern eher was ist der Referenzwert (Baseline) gegen die diese Tests laufen.
Aus meiner Sicht sollte das SIGNALduino Modul nur gegen Werte getestet werden, die damit auch erzeugt wurden.

from signalduino_tool.

Aus meiner Sicht sollte das SIGNALduino Modul nur gegen Werte getestet werden, die damit auch erzeugt wurden.

Dann nutze als Grundlage die JSON Datei wo der Wert Internal existent ist. Diese wurden von mir verglichen, das jeweils bei Euren beiden Varianten das gleiche raus kommt.

Wo der Wert Internal noch nicht existiert, da gibt es Differenzen bzw das wurde noch nicht getestet.

Anhand der Differenzen muss man dann zusammen schauen was richtig / falsch ist und wo der Fehler liegt ist mein Vorschlag. So sollten wir glaube auf einen Nenner kommen und „sicherstellen der Funktion“.

from signalduino_tool.

Das klingt gut.

Leider habe ich keine Angabe internal in der JSON Datei gefunden
Kannst Du mir da noch Hinweise geben?

from signalduino_tool.

Der aktuelle Stand ist in einem separaten Branch vorerst bis alles durchgetestet wurde.
https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/dev_JSON_v1/FHEM/lib/SD_Device_ProtocolList.json

Dort ist die aktuelle Datei.

from signalduino_tool.

Da wir ohne die passende Empfänger (ITR-3500 oder ITR-300) mit dem Senden der Gruppentaste anscheinend nicht weiterkommen,
könnt Ihr in der JSON-Datei bei der ID 3.1 das "i45FF15" in "i455515" abändern.
Ich ändere es dann bei mir auch so ab, daß es mit dem CUL kompatibel ist (F zu 01 (F) )

from signalduino_tool.