Signalduino Entwicklung

[Ralf9]

Ich habe mal ein wenig mit der matchListSIGNALduino rumgespielt.
Ist irgendwie seltsam. Es sieht bei mir so aus, als hätte die $hash->{Match} regex in den logischen Modulen vorrang.

Obwohl nach dieser Matchlist keine Nachrichten zum Hideki- und SIGNALduino_ID7-Modul übergeben würden dürften, Werden die Nachrichten mit dem Dispatcher zum $hash->{ParseFn} des Moduls übergeben und dort verarbeitet.

Code Auswählen Erweitern

Matchlist:
     1:IT       ^i......
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:Hideki   ^xx
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SIGNALduino_AS AS[A-Fa-f0-9]{7,8}
     7:SIGNALduino_ID7 ^aa[A-Fa-f0-9]{9}
     8:SIGNALduino_RSL ^rA-Fa-f0-9]+
     9:SIGNALduino_un u[1-6|8-9].*

Code Auswählen Erweitern

Hideki_Parse sduino incomming 58756BBACAE7BEC755D05B00
ID7_Parse u74E9091F49


Beim 41_OREGON.pm ist mir auch ein Fehler aufgefallen.
Am Ende ist ein " , " anstatt " ; "

Code Auswählen Erweitern

$hash->{Match}     = "^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*", #38-78


Durch die folgende Änderung in der "sub SIGNALduino_Hideki()" wäre in der Matchlist eine klare Trennung zwischen Hideki und Oregon möglich

Code Auswählen Erweitern

$hidekihex = "Hi" . $hidekihex; # Number of bits


Gruß Ralf

[Sidey]

Hi Ralf,

Ich glaube ich muss mir das von Rudi mal erklären lassen.
Ich habe das Gefühl dass die clientlist zuerst durchgearbeitet wird und erst danach die Matchlist.

Für die clientlist gibt es auch eine Reihenfolge, allerdings habe ich nicht verstanden, wie man sie manipuliert.


Grüße Sidey

[pejonp]

Hi Jörg,

Ich verstehe auch nicht, weshalb es da solche Probleme gibt.
....

Hallo Sidey,

ich habe ein paar Test durchgeführt. In die fhem.cfg habe ich nur den Aufruf für den Signalduino eingetragen.

define sduino SIGNALduino /dev/signald

und in der 00_SIGNALduino.pm alles rausgenommen bis auf  "3:Hideki". Damit wurden die Sensoren angelegt.
Dann  die anderen Einstellungen wieder aktiviert. Damit wurden die anderen Sensoren angelegt.
Nochmal ein update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt gemacht.
Auch alles ok.

Die alte fhem.cfg wieder hergestellt, aber vorher alle Einträge von CUL_TMC..,OREGON und Cresta entfernt. Und siehe da es geht. War also mein Fehler. Vielen Dank für deine Arbeit und Mühe.

Habe Firmeware 3.1.7 drauf. Läuft.

Jörg

[Ralf9]

Ich habe das Gefühl dass die clientlist zuerst durchgearbeitet wird und erst danach die Matchlist.

Ja, so sieht es aus.

Ich habe mir darüber auch mal Gedanken gemacht wie man das verbessern könnte.
Damit müssten dann im log auch die vielen "Unknown code" Meldungen vom dispatcher weg sein. Da es mir zuviel geworden ist habe ich beim sduino den verbose auf 2 gesetzt.

Dies müsste erreicht werden wenn am Ende der der Parseroutinen mit der in der ProtocolListSIGNALduino enthaltene modulematch regex geprüft wird.
In etwa so:

Code Auswählen Erweitern

my $modulematch = $ProtocolListSIGNALduino{$id}{modulematch};
if ($dmsg =~ $modulematch && $ProtocolListSIGNALduino{$id}{clientmodule} ne "undef")
{
SIGNALduno_Dispatch($hash,$rmsg,$dmsg);
$message_dispatched=1;
}



Bei einer leeren clientlist müsste nur die Matchlist verwendet werden
my $clientsSIGNALduino = ":"

Durch die modulematch regex Abfragen in den parse Routinen müsste eine vereinfachte Matchlist reichen:

Code Auswählen Erweitern


Matchlist:
     1:IT       ^i.*
     2:CUL_TCM97001 ^s.*
     3:Hideki   ^Hi75.*
     4:OREGON   ^([3-7]).*
     5:CUL_TX   ^TX.*
     6:SIGNALduino_AS ^AS.*
     7:SIGNALduino_ID7 ^u7.*
     8:SIGNALduino_RSL ^r.*
     9:SIGNALduino_un ^u[1-6|8-9].*


Gruß Ralf

[Sidey]

Hi Ralf,

Finde ich gut, dass Du dich da so eingelesen hast. Ich hab im Entwicklungs Forum mal eine Frage gestellt, wie das gedacht ist.
Vielleicht bringt uns das ja auch noch etwas weiter.

Damit müssten dann im log auch die vielen "Unknown code" Meldungen vom dispatcher weg sein. Da es mir zuviel geworden ist habe ich beim sduino den verbose auf 2 gesetzt.

Die kommen immer dann, wenn keines der logischen Module einen Erfolg gemeldet hat oder?
Also insbesondere von Protokollen die ich noch nicht richtig kenne.

Dies müsste erreicht werden wenn am Ende der der Parseroutinen mit der in der ProtocolListSIGNALduino enthaltene modulematch regex geprüft wird.

Diese Variable, habe ich vorgesehen um die ModuleMatch Liste per Konfiguration anpassen zu können.
Meine Idee ist, dass man sich in einem Attribut die unterstützten Protokolle aktiviert oder deaktiviert. So ähnlich wie bei den Räumen.

In etwa so:

Code Auswählen Erweitern

my $modulematch = $ProtocolListSIGNALduino{$id}{modulematch};
if ($dmsg =~ $modulematch && $ProtocolListSIGNALduino{$id}{clientmodule} ne "undef")


Bei einer leeren clientlist müsste nur die Matchlist verwendet werden
my $clientsSIGNALduino = ":"

Wenn in der Matchlist jetzt die identische Regex stehen würde wie in $modulematch.
Hätte man dann nicht den gleichen Effekt, wenn man Dispatch einfach ohne die Regex Abfrage in der parse Funktion ausführt.
Vom Prinzip, wird da ja nichts anderes gemacht.

Durch die modulematch regex Abfragen in den parse Routinen müsste eine vereinfachte Matchlist reichen:

Ich würde eher dazu tendieren, erst etwas ungenauer zu filtern und zum Schluss hin immer genauer zu werden.
Kann dir jetzt aber nicht genau sagen wieso.

Grüße Sidey

[Sidey]

Hi Jörg,

Die alte fhem.cfg wieder hergestellt, aber vorher alle Einträge von CUL_TMC..,OREGON und Cresta entfernt. Und siehe da es geht. War also mein Fehler. Vielen Dank für deine Arbeit und Mühe.

Hmm. Da bin ich mir nicht so sicher ob das wirklich an die lag.
Ich bin jetzt etwas schlauer, was diverse Verhalten angeht.

Kannst Du mir sagen, in welchem Zeitabstand ein Sensor eine Nachricht überträgt?
Am Autocreate wurde die Tage was verändert, das könnte Einfluss gehabt haben.

Grüße Sidey

[Ralf9]

Die kommen immer dann, wenn keines der logischen Module einen Erfolg gemeldet hat oder?

Die "Unknown code" Meldungen kommen, wenn der dispatcher kein Modul gefunden hat dem er eine Nachricht übergeben konnte.
Die Unknown Meldungen kommen auch, wenn in der Matchliste keine regex zu der Nachricht passt.
D.H. die Unknown Meldungen bekommen wir nur weg, wenn die regex in der parse Funktion genauer als in der Matchlist ist.

Diese Variable, habe ich vorgesehen um die ModuleMatch Liste per Konfiguration anpassen zu können.
Meine Idee ist, dass man sich in einem Attribut die unterstützten Protokolle aktiviert oder deaktiviert. So ähnlich wie bei den Räumen.

Ja, das ist eine sehr gute Idee. Macht aber IMHO nur sinn, wenn es Dir gelingt eine Auswahlbox wie beim room zu programmieren.
Es würde auch genügen ein Attribut "whitelist" zu haben wo man dann die IDs komma getrennt eintragen kann.


Beim Hideki ist mir was aufgefallen. Ab und zu werden Nachrichten mit 160 Bit empfangen die auch als ID10 erkannt werden.

Code Auswählen Erweitern


2015.10.09 22:27:58 3: protocol does not match return from method. id 10, clock 465 length 42 -> OSV2
2015.10.09 22:27:58 3: sduino: hideki protocol converted to hex: (Hi75E8BACA78BF21512F3675E8BA8A78BF215100) with length (160) bits, messagestart 0
2015.10.09 22:27:58 3: Found matched Protocol id 12, clock 465 length 42 -> Hideki protocol

Gruß Ralf

[Sidey]

Hi,

ich muss gerade mal ne neue Diskussion starten.

Die Sache ist folgende. Normalerweise, werden Funknachrichten mehrfach übertragen. Bei den Nachrichten, die mit einem klaren Sync anfangen, gebe ich derzeit nur eine einzige Nachricht aus. Alle Wiederholungen verwerfe ich. Bei meinen Wettersensoren, können das schon mal 6 Wiederholungen sein.

Jetzt habe ich ein bisschen darüber nachgedacht, wie man eigentlich Fehler in der Übertragung entdeckt. Entweder über eine Checksumme oder über den Vergleich mit Mehrfachen Übertragungen.


Ich bin mir jetzt etwas unsicher, ob ich alle Wiederholungen vom Arduino an den FHEM Sererver schicken sollte.

Ich habe das mal eingebaut und da kommt dann folgendes Gewitter für einen Wettersensor an.

Code Auswählen Erweitern


2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: Dropped (s58880CB43000) due to short time or equal msg
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;
2015.10.10 00:24:06 4: SIGNALduino/msg READ: MS;P0=-3392;P1=515;P2=-1926;P3=-3875;P4=-9196;D=14121312131312121213121212131212121212121213131212131213131213121212121313;CP=1;SP=4;O;


Wie man sieht, kommt die Nachricht mehrfach an und wird dann halt jedesmal verworfen, da nicht genügend Zeit vergangen ist.

Wenn man das so sieht ist es unsinnig. Beschäftigt habe ich mit dem Thema, da die Erkennung bei den Funksteckdosen manchmal nicht so astrein funktioniert.
Jetzt könnte man im FHEM eine Prüfung einbauen, wodurch der Befehl nur weitergegeben wird wenn x Wiederholungen erkannt wurden.

Ich könnte es auch auf dem Arduino vergleichen, dann müsste man aber so ne Art Checksumme oder so berechnen, sonst kostet das wieder so viel Speicher.


Grüße Sidey

[justme1968]

aktuell verwendet fhem die erste nachricht und verwirft die darauf folgenden duplikate.  wenn du auf fhem seite alle duplikate verwirfst und nur die letzte nachricht verwendest hast du doch den gleichen aufwand und zusätzlich eine größere verzögerung. ich glaube das wäre z.b. für schalter und lampen nicht ideal.

wenn du aber meinst das du nur nachrichten die auf jeden fall z.b. zwei mal identisch empfangen wurden überhaupt berücksichtigen willst gehört das auf den arduino. das würde die systemlast tatsächlich senken.

gruss
  andre

[Ralf9]

Die Sache ist folgende. Normalerweise, werden Funknachrichten mehrfach übertragen. Bei den Nachrichten, die mit einem klaren Sync anfangen, gebe ich derzeit nur eine einzige Nachricht aus. Alle Wiederholungen verwerfe ich. Bei meinen Wettersensoren, können das schon mal 6 Wiederholungen sein.

Das geht dann wahrscheinlich nur bei den MS-Nachrichten. Wie machst Du es aktuell im Arduino mit den Wiederholungen bei den MC- und MU-Nachrichten?
Oder kann man davon ausgehen, daß die meisten Funksteckdosen MS Nachrichen senden?

Ich bin mir jetzt etwas unsicher, ob ich alle Wiederholungen vom Arduino an den FHEM Sererver schicken sollte.

Du könntest die Anzahl der Wiederholungen auch mit einem set-Befehl konfigurierbar machen. z.B. set MSrepeat <anzahl>
und dann mit get config auslesen und ins reading schreiben.

Gruß Ralf

[Sidey]

Hi Ralf,

Bei Mu wird alles ausgegeben was vorhanden ist.
Dabei können auch Wiederholungen ausgegeben werfen, da ich im Arduino nicht zweifelsfrei erkennen kann, wo die Übertragung einer Nachricht beginnt / endet.

Bei den Mc Nachrichten wird aktuell nur eine übergeben. Das könnte ich noch anpassen, dass auch eine 2. übergeben wird.

Die gängigen Funksteckdosen verwenden Signale mit Sync. Ich habe auch noch eine die sendet ohne Sync und kenne noch ein weiteres System.
Da müssten die Wiederholungen  in Fhem ausgewertet werden. Im Arduino sehe ich da aktuell keine Chance.

Die Ms Nachrichten könnte man im Arduino über eine crc8 Routine vergleichen.
Ich weiss nur noch nicht, wie man das effizient implementiert. Immerhin weiss ich ja nicht, welche der Übertragungen die korrekte ist.

Wenn ich nun die 1. mit der 2. vergleiche und der crc stimmt nicht, dann weiss ich ja nicht, welche Übertragung nun fehlerhaft ist. Also muss ich eine 3. prüfen und dann gegen beide wieder vergleichen. Stimmt keiner, ist alles Müll oder irgendwas unerwartetes ist passiert.

Wenn zwei oder drei Nachrichten nicht in den Puffer passen, müsste man sich auch was überlegen. Bei Funksteckdosen aktuell kein Problem. Es passen derzeit ca. 120 Bit in den Puffer. Eine MS Nachricht hat meist nicht mehr als 40 Bit. Zwei passen also immer rein.

Grüße Sidey

[Sidey]

Hallo Ralf,

Die "Unknown code" Meldungen kommen, wenn der dispatcher kein Modul gefunden hat dem er eine Nachricht übergeben konnte.

Das sollte ja eigentlich nicht in unserem Fall auftreten.

Die Unknown Meldungen kommen auch, wenn in der Matchliste keine regex zu der Nachricht passt.
D.H. die Unknown Meldungen bekommen wir nur weg, wenn die regex in der parse Funktion genauer als in der Matchlist ist.

Hmm, bist Du dir da sicher? Ich würde das prüfen viel lieber der Dispatch Funktion überlassen.

Ja, das ist eine sehr gute Idee. Macht aber IMHO nur sinn, wenn es Dir gelingt eine Auswahlbox wie beim room zu programmieren.
Es würde auch genügen ein Attribut "whitelist" zu haben wo man dann die IDs komma getrennt eintragen kann.

Das ist vermutlich eine Fleißarbeit... deshalb ist es auch noch nicht umgesetzt.

Beim Hideki ist mir was aufgefallen. Ab und zu werden Nachrichten mit 160 Bit empfangen die auch als ID10 erkannt werden.

Code Auswählen Erweitern


2015.10.09 22:27:58 3: protocol does not match return from method. id 10, clock 465 length 42 -> OSV2
2015.10.09 22:27:58 3: sduino: hideki protocol converted to hex: (Hi75E8BACA78BF21512F3675E8BA8A78BF215100) with length (160) bits, messagestart 0
2015.10.09 22:27:58 3: Found matched Protocol id 12, clock 465 length 42 -> Hideki protocol
Gruß Ralf

Die Nachricht ist zweimal da. Wird also direkt hintereinander ohne Pause übertragen.
Das wird für das IODev Modul etwas schwierig zu erkennen, da es das Ende ja nicht kennt. Das ganze Hideki Protokoll würde ich ja lieber in dem Hideki Modul verarbeiten.
Das macht die Regex nun aber etwas schwierig. Insbesondere, da die 2. Nachricht auch noch 2x 00 hat.
Als sehr einfache Lösung könnte ich mir Vorstellen man prüft in

Code Auswählen Erweitern

SIGNALduino_Hideki nach 0x75 ein 2. mal.

Als ich gerade noch mal die Längenprüfung für MC Signale angesehen habe ist mir aufgefallen, dass ich sonst immer die Anzahl der Bits prüfe.
Bei den MC Messages, sind es aber nicht bits, sondern nibble. Anders gesagt, unter 80 bit (20 nibble) wird erst gar nichts als hideki erkannt.
So macht das bei den MC Messages aber dann wohl wenig Sinn. Die Längenprüfung sollte man wohl erst machen, wenn man weiß, wo das Signal beginnt.

in SIGNALduino_Hideki könnte man in etwa folgendes machen:

Code Auswählen Erweitern



my $message_start=index($bitData,"10101110");
my $message_end=length($bitData);

if (index($bitData,"0101110",$message_start+9) >= 0 )   # 0x75 ein zweites mal gefunden
        {
            message_end=index($bitData,"0101110",$message_start+9)
        }
        if (length($bitData) >= $ProtocolListSIGNALduino{$id}{length_min}*4 and length($rawData) <= $ProtocolListSIGNALduino{$id}{length_max}*3)
        {
            ## convert to hideki hex...
        }

Naja, noch besser wäre vielleicht das ganze in eine schleife zu packen und zu checken ob die Wiederholung auch identisch zur 1. Nachricht ist.
Auf jeden Fall wissen wir jetzt, dass nur Sensoren erkannt werden, welche die Nachricht mindestens 2x hintereinander ohne Pause übermitteln.
Irgendwer hatte mich auch mal gefragt, wieso das dekodieren nicht klappt, wenn zum Senden die Lib von Randy Simons verwendet wird. Ist mir jetzt klar, denn er hat in seiner lib einen delay von 30 ms vor einer Wiederholung eingebaut. Wobei er auch noch Byte 3 verändert.... ganz komische Sache also.

Vermutlich gibt es auch Sensoren die sich genau so verhalten.
Daraus ergeben sich erst mal folgenden Todos im Zusammenhang MC und Hideki:

• Wiederholungen in MC Messages erkennen und separieren
• Wiederholungen Protokollspezifisch auswerten, ggf. via fingerprintFn()
• Längenangabe und Prüfung überarbeiten

Zur Matchlist und Clientlist, bin ich immer noch nicht schlauer.
Ich hatte zwischenzeitlich angenommen, dass man die Clientlist nur für sendende Module noch benötigt und mit der Matchlist auskommen kann.
Die Annahme wurde aber leider nicht bestätigt. Weiterhin beeinflusst die Zahl vor dem Modulnamen also 41_OREGON oder 10_Hideki die Sortierreihenfolge in der Clientlist. In der Matchlist wird diese ja manuell angegeben.

Ich würde aber trotzdem mal dazu tendieren, nur die Sendenden Protokoll in die Clientliste zu setzen und alles andere über die Matchlist laufen zu lassen.
Wenn ich den Code verstanden habe, sollte das doch laufen.


Grüße Sidey

[Ralf9]

Das sollte ja eigentlich nicht in unserem Fall auftreten.
Hmm, bist Du dir da sicher? Ich würde das prüfen viel lieber der Dispatch Funktion überlassen.

Ich würde es gerne so machen:
Vor dem Dispatch prüfen ob  $ProtocolListSIGNALduino{$id}{clientmodule}   ungleich  'undef'
und wenn in $ProtocolListSIGNALduino{$id}{modulematch} eine regex steht, diese vor dem dispatch prüfen.
Dies macht vorallem bei genauen regex wie beim Hideki- und ID7-Modul Sinn, damit der dispatcher bei fehlerhaft empfangenen Nachrichten unnötigerweise "beschäftigt" wird und um die unknown Meldungen zu vermeiden.

Das ist vermutlich eine Fleißarbeit... deshalb ist es auch noch nicht umgesetzt.

Ja, das hast richtig erkannt.
Ich würde es mit einem Attribut machen das z.B. "whitelist_IDs" heißt. Dort werden dann die IDs komma getrennt eingetragen.

Als sehr einfache Lösung könnte ich mir Vorstellen man prüft nach 0x75 ein 2. mal.

Ja, das würde ausreichen. In der MC_Parse macht es wahrscheinlich nur Sinn nach der length_min zu prüfen. Der Rest dann in der SIGNALduino_Hideki().

Zur Matchlist und Clientlist, bin ich immer noch nicht schlauer.
Ich hatte zwischenzeitlich angenommen, dass man die Clientlist nur für sendende Module noch benötigt und mit der Matchlist auskommen kann.
Die Annahme wurde aber leider nicht bestätigt. Weiterhin beeinflusst die Zahl vor dem Modulnamen also 41_OREGON oder 10_Hideki die Sortierreihenfolge in der Clientlist. In der Matchlist wird diese ja manuell angegeben.
Ich würde aber trotzdem mal dazu tendieren, nur die Sendenden Protokoll in die Clientliste zu setzen und alles andere über die Matchlist laufen zu lassen.
Wenn ich den Code verstanden habe, sollte das doch laufen.

Ich habe hier nachgefragt und justme1968 hat es mir sehr geduldig erklärt.
http://forum.fhem.de/index.php/topic,42018.msg342686.html#msg342686
Nun sind mir die Zusammenhänge klar geworden. Es macht keinen Sinn nur die Sendenden Protokolle in die Clientliste zu setzen, dies hat Nachteile.


Ich würde die Prüfungen vor dem dispatch und das mit dem "whitelist_IDs" Attribut gerne einbauen.
In der SIGNALduino_Hideki() habe ich auch noch einen Fehler gefunden. Die Prüfung nach dem 2.mal 0x75 werde ich dann auch versuchen einzubauen.

Hast Du Dich mittlerweile entschieden ob Du das ID7 Modul umbenennen willst?
SD_WS07    -> SIGNALDuino WeatherSenser ID 07
wäre ok.

Für mich wäre das ganze einfacher, wenn es im github einen stabilen und einen dev Branch geben würde. Damit ich die Bresser/Hama und den Eurochron Temperatursensor verwenden kann, muß ich bei mir eine eigene Version der 00_SIGNALduino.pm pflegen und Deine Änderungen im dev-rawin Branch kann ich nicht verwenden und testen.
Ich würde es praktischer finden, wenn aus dem jetzigen dev-rawin Branch der stabile Branch würde und wenn Du aus den 3 Branches  dev-rawin, dev-cresta und dev-proto7 einen dev-Branch machen würdest. Falls Du den Aufwand des umbenennens vom ID7 Modul machen willst, kannst Du dort gleich die umbenannte Datei reinlegen. Ich könnte Dir beim Umbenennen etwas helfen.

Gruß Ralf

[Sidey]

Hallo Ralf,

Ich hoffe ich bekomme jetzt alles zusammen. Im großen und ganzen bin ich bei dir.

Whitelist:
Ja, kann man als schnelle Lösung machen. Bin aber nicht sicher, ob eine Blacklist nicht besser wäre.  Wenn neue Protokolle stabil implementiert werden, funktionieren sie mit der Whitelist nicht.
Langfristig sollte die Auswahlliste her.

Proto7:
Ja das benennen wir jetzt SD_WS07. Auch wenn ich die Abkürzung Sd eher für Sensor Device gesehen hatte...
Ich mache das im Branch.

Master /Stable:

Ja, ich will eine neue Master Stable machen. Ich schaffe nur dauernd den Absprung nicht.

Dazu folgende Idee, die Änderungen überschaubar halten:

Rawin-> Master  v 3.1.8
1. Alle Protokolle,  welche wir nicht dekodieren können, werden deaktiviert. Demnach bleibt IT,Cul_TCM97001, TX2 und Oregon  aktiv. 
2. In parseMC wird die Prüfung auf max Länge entfernt und die Angabe in  Längen  Variable wird von nibble auf Bit geändert.( betrifft nur Manchester Protokolle)
Kann man ja dann in nibble umrechnen.
, wo es notwendig ist.
3. Firmware wird noch mal aktualisiert, habe einen Fehler in die letzte eingebaut. Neue Version läuft bei mir schon zum Test.
4.Commandref aktualisieren. Da ist noch immer ein Bug in der Formatierung. Den muss ich noch finden.
5. Diese Version wird dann zum Master und kommt auch in das normale Fhem update als 3.1.8 oder so.
6.. Im Master werden dann nur noch Fehler behoben...

Dee Zweig dev-rawin müsste dann eigentlich geschlossen werden. Geht aber vermutlich noch nicht.

Dev-cresta und dev-proto7:
1. Umbenennen von proto7 in SD_WS07.pm
2. Commandref von hideki und ws07 Modul anpassen.
3. Wiederholung der Nachricht aus cresta filtern. Dadurch wird vermutlich das Problem mir Oregon auch gelöst.
4. Die Daten erhalten ein Präfix nach dem Schema P<ID>#<Nachricht> wenn P noch nicht verwendet wird.
5. Beide Zweige in dev-rawin über führen.
6. Dev-rawin umbenennen....

Danach implementieren wir white oder blacklist, Clientlist / MatchList und sonstige Regex Prüfungen..
Das könnte man dann wieder in den Master über führen. v 3.2.x
Eventuell auch was zur Du pl in stärken jung Im Arduino mit crc oder so.

Damit ich den Überblick nicht verliere, sollten wir die Todolisten als Issue in github  pflegen und dort abhaken.

Grüße Sidey

[Ralf9]

Whitelist:
Ja, kann man als schnelle Lösung machen. Bin aber nicht sicher, ob eine Blacklist nicht besser wäre.  Wenn neue Protokolle stabil implementiert werden, funktionieren sie mit der Whitelist nicht.

Ich würde bei der stable/master die whitelist mit den decodierbaren IDs vorbelegen, dann brauchst Du nichts deaktivieren.
Und bei der dev würde ich die whitelist nicht vorbelegen, da kann jeder die ids eintrager die er möchte.

Master /Stable:

Ich würde das Hideki mit ins stable übernehmen.
Ich habe bei mir die Entfernung des 2. 75 eingebaut.
Die whitelist habe schonmal beim MS_Parse eingebaut.
Ich werde diese beide Änderungen ins dev-cresta einchecken.
Kannst Du dann die dev-rawin und die  dev-cresta zur master zusammenführen?

In parseMC wird die Prüfung auf max Länge entfernt und die Angabe in  Längen  Variable wird von nibble auf Bit geändert.( betrifft nur Manchester Protokolle)

Ich denke das ist doch nicht notwendig, es funktiioniert bei mir auch so.

Gruß Ralf