Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

Begonnen von Sidey, 02 Oktober 2016, 23:39:11

Vorheriges Thema - Nächstes Thema

Sidey

Hallo,

Edit 20.03.3029:
Version 3.3.3 ist ab 21.02.2019 im FHEM Update verteilt.

  • Neues Menü Display protocollistlist im FHEMWEB um die Verarbeitung von Protokollen aktivieren/deaktivieren zu können
  • Definition der Protokolle zum demodulieren sind in eine separate Datei ausgelagert.
  • Etliche Verbesserungen beim Demodulieren von Signalen
  • Optional können neben dem Loggin in das FHEM Log auch Events generiert werden
  • Herunterladen und Flashen von Firmware ist direkt aus dem FHEM Modul (für AVR Boards) möglich



Erweiterungen der Vorgängerversion:

  • Blacklisting of protocols via attribute
  • Flamingo smoke detector (FA20 /FA21)  bislang nicht stabil

Ende der Änderung.

Es haben leider nicht alle Erweiterungen aus der Entwicklungsversion in 3.3.1 geschafft.
Da mir das letzte Update viel zu lange gedauert hat und sich etliche Erweiterungen bewährt haben, gibt es diese jetzt als Version 3.3.1.

Die Modulversion 3.3.1 ist vollständig mit der Firmware 3.3.0 kompatibel. Deshalb gibt es auch keine neue Firmware. Ein neu flashen ist also nicht notwendig!


In das Update haben es Folgende Anpassungen geschafft:

  • Fehler in der Datenverarbeitung gefunden, der zu einer Endlosschleife führen konnte
  • CPU Nutzung durch diverse Optimierungen reduziert
  • Es ist das senden mehrerer Funkbefehle ohne Delay möglich. Das Modul kümmert sich darum, dass erst gesendet wird, wenn die vorherige Nachricht fertig gesendet wurde.
  • Ein neuer Sensortyp Bresser Temeo wird im SD_WS Modul unterstützt
  • Diverse kleine Warnmeldungen und Fehler behoben
  • Neuer Befehl get protocolIds zum Anzeigen der Protokolle und deren Bezeichnung


Geplant waren noch zwei Erweiterungen die es aber bislang nicht geschafft haben:

  • Direct Ethernet Support with microcontroller
  • Blacklisting of protocols via attribute
  • Flamingo smoke detector (FA20 /FA21)  bislang nicht stabil


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Mir ist immer noch nicht klar zu was eine Blacklist bei mittlerweile 50 Protokollen gut sein soll.
Beim produktiven Einsatz werden doch normalerweise in der whitelist die Protokoll Ids eingetragen die man empfangen möchte.

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

Sidey

Ich weiss was Du meinst, es ist aber auch denkbar, dass man alle möglichkeiten Protokolle empfangen können will und nur ein paar Sachen mittels Blacklist ausschließen möchte.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

#3
Zitat von: Ellert am 04 Oktober 2016, 12:34:34
Nach dem die offizielle Version des SD SOMFY unterstützt, habe ich den nanoCUL und den FHEMduino durch den SIGNALduino ersetzt.

Ich habe einen Intertechno Funk-Bewegungsmelder PIR-1000, der nutzt das Protokoll IT-V3 und wird auch empfangen.

Mir fiel es aber schwer, den richtigen Eintrag für die Whitelist zu finden.

Wenn ich in den Quellcode des Moduls schaue, dann finde ich nur Id. 3 für itv1, mit dem Eintrag funktioniert es nicht.
Im WIKI steht für IT Id. 3,4,5,17 mit 17 funktioniert es, aber das ist im Quellcode mit "arctech" und man muss probieren.
Auf 17 bin ich aber gekommen, weil mit verbose 5 bei Betätigung des Bewegungsmelders häufig die Id. 17 zu sehen war.

Wäre es wünschenswert, wenn bei dem Attribut "whitelist_IDs" eine mehrfach selektierbare Liste hinterlegt werden würde?

Diese Liste könne z.B. aus der Variablen "%ProtocolListSIGNALduino" abgeleitet werden, über "id", "name".

Eventuell könnte "%ProtocolListSIGNALduino" um Einträge erweitert werden, wie "commonname" der dann Markennamen enthält oder weitere Angaben zu eindeutigen Zuordnung, "messagetype" der dann den zu aktivierenden Messagetype enthält.

Die mehrfach selektierbare Liste wird dann aber sehr groß werden, z.Zt. gibt es ca 50 Protokolle.
Ich würde es mit einem get Befehl machen.
z.B. get ProtocolList
mit der Möglichkeit zu filtern ob alle Protokoll Ids oder nur die, für die es Module gibt, in einer Liste ausgegeben werden.
In der Liste werden dann die Id und die Felder clientmodule und name ausgegeben.

In der ProtocolListSIGNALduino wäre dann ein weiteres Feld "Kommentar", das man dann mit ausgeben könnte, sinnvoll.

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

Ellert

#4
Zitat von: Ralf9 am 04 Oktober 2016, 14:45:29
Die mehrfach selektierbare Liste wird dann aber sehr groß werden, z.Zt. gibt es ca 50 Protokolle.
Ich würde es mit einem get Befehl machen.
z.B. get ProtocolList
mit der Möglichkeit zu filtern ob alle Protokoll Ids oder nur die, für die es Module gibt, in einer Liste ausgegeben werden.
In der Liste werden dann die Id und die Felder clientmodule und name ausgegeben.

In der ProtocolListSIGNALduino wäre dann ein weiteres Feld "Kommentar", das man dann mit ausgeben könnte, sinnvoll.

Gruß Ralf
Ja, nachdem ich mir den Code angesehen habe, ist für mich der Eingriff in das Attribut "whitelist_IDs" recht groß.

Ich habe mal get protocolIDs eingebaut, mit dem was vorhanden ist. Damit sieht man wenigstens die Protokolle und weiss welchen Messagetype man aktivieren muss.

Da ich keinen Github Account habe, poste ich die Änderung mal hier:

Zeile 58:
   "protocolIDs"   => ["none",'none'],

ab Zeile 1408:
  if ($a[1] eq "protocolIDs")
  {
my $ret;
my $id;
foreach $id (keys %ProtocolListSIGNALduino)
{
next if ($id eq 'id');

if (exists ($ProtocolListSIGNALduino{$id}{format}) && $ProtocolListSIGNALduino{$id}{format} eq "manchester")
{
$ret .= sprintf("%4s",$id)." MC $ProtocolListSIGNALduino{$id}{name} \n";
}
elsif (exists $ProtocolListSIGNALduino{$id}{sync})
{
$ret .= sprintf("%4s",$id)." MS $ProtocolListSIGNALduino{$id}{name} \n";
}
elsif (exists ($ProtocolListSIGNALduino{$id}{clockabs}))
{
$ret .= sprintf("%4s",$id)." MS $ProtocolListSIGNALduino{$id}{name} \n";
}
}
return "$a[1]: \n\n$ret";
  }


Ausgehend von der offiziellen Version :00_SIGNALduino.pm 12233 2016-10-01 22:22:51Z mrsidey

die Geänderte Datei ist angehängt.

Ralf9

#5
ZitatIch habe mal get protocolIDs eingebaut

Danke für die Vorarbeit, ich bin gerade dabei es noch etwas zu erweitern.

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

Sidey

Das sieht super aus. Danke für die Unterstützung.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ellert

Ich wollte gerade meinen Code updaten, das ist ja nicht mehr notwendig.

Ich dachte an Überschriften
my $ret = "$a[1]:\n"."  ID MT ".sprintf("%20s","Protocolname").sprintf("%16s","Modulename")."\n".("-" x 50)."\n";


Ralf9

#8
Ich habe das "get protocolIDs" ins dev-r33 comitted

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt

Edit: Überschrift ergänzt.

Edit2:
und falls jemand eine blacklist benötigt, kann er die IdListe am Ende der protocolID Liste in die whitelist kopieren und die nicht benötigten Ids entfernen.
Daß jemand alle restlichen Ids, für die es kein Modul gibt, benötigt dürfte nicht wirklich sinnvoll sein.

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

Ellert

Ich habe mal eine Blacklist-Funktionalität eingebaut, falls es noch erwünscht ist.
Grundlage ist: $Id: 00_SIGNALduino.pm 10484 2016-10-04 20:00:00Z v3.3.1-dev $

Wird das Attribut blacklist_IDs gesetzt, dann wird das Attribut whitelist_IDs als Komplement gesetzt/überschrieben.
Wird danach whitelist_IDs geändert, gilt das solange bis blacklist_IDs geändert wird.
Wird blacklist_IDs gelöscht, wird auch  whitelist_IDs gelöscht.


Zeile 978
  ." blacklist_IDs"


ab Zeile 2870
elsif ($aName eq "blacklist_IDs")
{
if (defined($aVal) && length($aVal)>0)
{
# erstellt die whitelistIDs als Komplement blacklistIDs
my @black = split(",", $aVal);
my @white;
my $i1;
foreach $i1 (keys %ProtocolListSIGNALduino)
{
push(@white, $i1) unless ($i1 ~~ @black);
}
fhem "attr $name whitelist_IDs ".join(",", sort(@white))."; save";
}
else
{
fhem "deleteattr $name whitelist_IDs; save";
}
}


Sidey

Sollten wir einen Set Befehl einbauen, der in der whitelistID nur die Protokolle einträgt, zu denen es auch ein logisches Modul gibt?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Zitat von: Sidey am 06 Oktober 2016, 09:12:15
Sollten wir einen Set Befehl einbauen, der in der whitelistID nur die Protokolle einträgt, zu denen es auch ein logisches Modul gibt?

Dem spricht dagegen, daß das Modul keine Attribute ändern sollte, da die Attribute dem user gehören.
Diese Liste gibt es schon am Ende der Liste von "get protocolIDs".

Ich würde die Blacklist einbauen, wenn es Bedarf und eine konkrete sinnvolle Anwendung gibt.

Oder sollen wir die Blacklist einbauen ohne das dafür konkreter Bedarf besteht?

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

Sidey

Also Bedarf an einer Blacklist ist immer dann da, wenn man von neuen Prorokollen ohne Anpassung der Konfig profitieren möchte.

Ich würde es aufnehmen und dem Anwender die Option überlassen, ob er mit der Whitelist oder mit der Blacklist arbeiten möchte.

80℅ der Anwender sind bestimmt mit der Whitelist gut bedient.


Anderes Thema:

Die meiste CPU Zeit verbraucht unsere read Funktion.
Lässt sich diese optimieren?
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Zitat von: Sidey am 14 Oktober 2016, 15:47:58
Also Bedarf an einer Blacklist ist immer dann da, wenn man von neuen Prorokollen ohne Anpassung der Konfig profitieren möchte.

Das ist mir nicht klar, welche Protokolle werden in diesem Fall in die Blacklist eingetragen?

Zitat
Die meiste CPU Zeit verbraucht unsere read Funktion.

Wie ermittelst Du die CPU Zeit?
Gehören die CPU Zeiten der SIGNALduino_Parse Funktionen auch zur read Funktion?
Wird die verbrauchte CPU Zeit der read Funktion deutlich weniger, wenn du mit "set disableMessagetype unsyncedMU" die MU-Nachrichten deactivierst und in die whitelist nur ein paar IDs einträgst?

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

Sidey

Zitat von: Ralf9 am 14 Oktober 2016, 17:57:41
Das ist mir nicht klar, welche Protokolle werden in diesem Fall in die Blacklist eingetragen?
Die, welche einen akut stören.

Zitat von: Ralf9 am 14 Oktober 2016, 17:57:41
Wie ermittelst Du die CPU Zeit?
Gehören die CPU Zeiten der SIGNALduino_Parse Funktionen auch zur read Funktion?
Ich habe es mir mittels apptime angesehen.

Ich nehme an, es wird alles gezählt, was nach SIGNALduino_read passiert, also auch SIGNALduino_Parse ..
Mit Whitelist ID habe ich nicht noch nicht gemessen. Es scheint mir halt schon eine recht hohe CPU Zeit im Durchschnitt verbraucht zu werden.
MU Nachrichten zu deaktivieren hilft ja nur in sofern, dass es dann weniger Requests sind, welche zu verarbeiten sind.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker