Signalduino Entwicklung

[Ralf9]

Wo finde ich denn eine Aufstellung der IDs?

In der 00_SIGNALduino.pm findest Du bei
my %ProtocolListSIGNALduino = (
eine Aufstellung der IDs.

Bei den IDs wo die preamble mit u beginnt gibt es noch kein Modul.   

Gruß Ralf

[RappaSan]

Danke, das hilft schon mal weiter.
Übersichtlich ist aber was anderes. Könnte man die ID nicht zusätzlich als attr ähnlich wie "model" aufnehmen und anstatt whitelist eine blacklist einführen?
Ich weiß - da muß wieder jede Menge code geändert werden.

[Sidey]

Ich würde es besser finden, wenn wir den aktuellen dev-32 Branch z.B. als 32 Branch behalten könnten.
Diese Version ist dann für diejenigen gedacht, die noch eine etwas ältere Firmware haben und nicht auf die neue Firmware updaten wollen oder ein update nicht so einfach möglich ist.

Reicht es nicht aus, wenn man sich die 3.2.0 Firmware selbst herunterlädt oder direkt aus dem commit holt wenn man die wirklich benötigt?

Den dev-r32-mcspecial Branch würde ich dann dev-33 nennen und dann als 3.3.0 als neue master nehmen.
Zwischen dem dev-32 Branch und dem dev-r32-mcspecial sind ja bei den mc Nachrichten einige größere Änderungen vorgenommen worden. Die nicht ganz aktuelle r32 Firmware wird wahrscheinlich bei den mc Nachrichten nicht mehr mit dem dev-r32-mcspecial funktionieren

Geht prinzipiell auch, aber eigentlich wollte ich in Versio 3.2 bleiben. Wenn die aktuelle Entwicklung ohnehin zum Master wird, dann wird die 3.2 doch eh keiner mehr nutzen.
Die Firmware in devr32 würde auch mit dem Modul aus dev-r32-mcspecial laufen, da am Modul nicht wirklich was geändert wurde.

Beides ist möglich, weiterentwickeln wollte ich dann halt nur noch eine Version

Grüße

[Sidey]

Code Auswählen Erweitern


2016-08-03 16:02:30-MC;LL=-1024;LH=926;SL=-519;SH=482;D=9FDA6F9F37800AE7CFED37CF9BC00573E7F69BCFED37CF9BC00573E7F69BE7CDE002B9F3FB4DF026F;C=486;L=324;#
2016-08-03 16:03:04-MU;P0=168;P1=-1033;P2=886;P3=420;P4=-570;P5=320;P7=-8192;D=0121343454543434343424343134342134542127;CP=3;#
2016-08-03 16:03:05-MC;LL=-1050;LH=882;SL=-556;SH=429;D=0EBD7A77DEBFFDEDD7E;C=486;L=75;#
2016-08-03 16:03:24-MC;LL=-1029;LH=918;SL=-530;SH=469;D=E7F69BE7CDE002B9F3FB4DF3E6F0015CF9FDA6F9F378;C=488;L=173;#
2016-08-03 16:03:26-


Sind das deine OSV3 Sensoren oder ist dir das einfach nur aufgefallen, dass es einige Nachrichten gibt, die nicht dekodiert werden?

[Sidey]

Übersichtlich ist aber was anderes. Könnte man die ID nicht zusätzlich als attr ähnlich wie "model" aufnehmen und anstatt whitelist eine blacklist einführen?

Ja super übersichtlich ist es nicht. Im Wiki stehen halt auch nur wenige Protokolle und somit IDs.
Das mit der blacklist hatte ich auch schon mal überlegt. Die Idee mit der Whitelist ist halt, ich weiss welche Protokolle ich empfangen möchte und die lege ich fest.
Wenn das Modul jetzt in 3 Wochen 10 neue Protokolle kann, will ich ja nicht dauernd meine Blacklist erweitern

So mega viel Code wäre das vermutlich nicht, da wir die Festlegung, welche Protokolle ausgewertet werden, bereits zentral vornehmen.
Was meinst Du aber mit einem attr ähnlich model. Kannst Du das genauer erklären?

Grüße Sidey

[Ralf9]

Die Firmware in devr32 würde auch mit dem Modul aus dev-r32-mcspecial laufen, da am Modul nicht wirklich was geändert wurde.

In der dev-r32-mcspecial gibt es bei der ID 10 "polarity => 'invert'"
Funktioniert damit mit der devr32 Firmware noch das OSV2o3?

Gruß Ralf

[Sidey]

In der dev-r32-mcspecial gibt es bei der ID 10 "polarity => 'invert'"
Funktioniert damit mit der devr32 Firmware noch das OSV2o3?

Erwischt... dieses Protokoll wird dann nicht mehr korrekt Dekodiert.
Das liegt daran, dass die alte Firmware die Signale invertiert zur jetzigen IEEE Variante gewertet hat.

Es stürzt aber nichts ab und wenn man ein MC Protokoll verwendet, wäre meine Empfehlung auch die aktuelle Firmware zu verwenden.

Grüße Sidey

[RappaSan]

Ich meine das wie z.B. bei diversen Sensoren wie im beigefügten Screenshot.
Wenn das in ähnlicher Art bei der Definition des sduino verfügbar wäre, könnte man evtl. mit Namen anstatt mit Nummern operieren.
Einfach mal so ins Unreine gesprochen...

[Burny4600]

Anbei ein Logauszug betreffend Perl Warning.

[Sidey]

Ich meine das wie z.B. bei diversen Sensoren wie im beigefügten Screenshot.
Wenn das in ähnlicher Art bei der Definition des sduino verfügbar wäre, könnte man evtl. mit Namen anstatt mit Nummern operieren.
Einfach mal so ins Unreine gesprochen...

In dem Beispiel kann man dem Gerät genau ein Modell auswählen. Das ist für den SIGNALduino unbrauchbar.

Wenn ich verstehe wie es von der Bedienung besser ist, sette ich es auch gerne um, soweit das möglich ist.

Grüße Sidey

[nicor2k]

Ich war gerade dabei, einen Arduino mit dem fhemduino zu flashen (oder das zu versuchen), weil da der FA20 / FA21 Rauchmelder anscheinend schon richtig unterstützt wird. Kann man nicht einfach die Angaben aus dem 14_FHEMduino_FA20RF.pm übernehmen?

Wenn ihr mir sagt, was ich dafür tun muss, mache ich das auch und stell die dann online

[Sidey]

Ich weiss nicht genau, was das Modul für Funktionen kann.

Aber ich nehme an Du kannst alles mit einem doif / notify realisieren, was so ein Rauchmelder macht.

Das Modul lässt sich sicher auch sehr einfach für den SIGNALduino anpassen.

Was genau willst Du denn realisieren?

Grüße Sidey

[nicor2k]

Ich habe jetzt gerade einen 2. Arduino mit fhemduino geflasht (parallel zu dem mit Signalduino . Die Rauchmelder werden da aber noch nicht erkannt, dafür irgendeinen Temperatursesor.

Ich habe den Rauchmelder mit einem DOIF über den Signalduino zwar eingebunden und kann sie meisten mit dem Senden von RAW Befehlen auch auslösen, aber beim FHEMduino scheint das sogar mit "on" und "on-for-timer" zu gehen - das wäre ja schon noch einmal etwas komfortabler. Mein Perl ist sehr eingerostet und ich habe mich auch noch nie mit der Modulentwicklung beschäftigt.  Kann man irgendwo nachlesen, was man da umändern muss?

[Ralf9]

Geht prinzipiell auch, aber eigentlich wollte ich in Versio 3.2 bleiben. Wenn die aktuelle Entwicklung ohnehin zum Master wird, dann wird die 3.2 doch eh keiner mehr nutzen.

Ich hätte gerne, daß die aktuelle dev-r32 weiterhin verfügbar bleibt. Sie muss nicht mehr bearbeitet werden können, aber ein
"update all https://raw.githubusercontent.com/.." sollte möglich sein.

Wenn die dev-r32-mcspecial dann zur Version 3.3.0 wird, dann haben wir eine eindeutige Trennung.
Wegen der Invertierung  werden dann bei der neuen Version mit der dev32 Firmware Sensoren mit dem MC Protokoll nicht mehr funktionieren.

Damit die dev-r32-mcspecial zur aktuellen Version werden kann, sollte erst noch getestet werden ob die Oregon V2 und V3 und Maverick Sensoren erkannt werden.


Ich habe mal mit der akuellen dev-r32-mcspecial einen Hama TS33C getestet.
So wies aussieht bin ich der erste der damit das Hideki Protokoll getestet hat.
Damit es funktioniert muß noch bei der ID 12 das  "polarity => 'invert'"  ergänzt werden.

Gruß Ralf

[Sidey]

Ich habe den Rauchmelder mit einem DOIF über den Signalduino zwar eingebunden und kann sie meisten mit dem Senden von RAW Befehlen auch auslösen, aber beim FHEMduino scheint das sogar mit "on" und "on-for-timer" zu gehen .

Kannst Du genauer erläutern, wozu das gut ist?
Du möchtest den Rauchmelder via FHEM auslösen?
On hast Du ja bereits mit einem Raw sendebefehl realisiert.
On-For-Timer wird ja wohl realisiert in dem nach einer Zeit X ein off Befehl gesendet wird.

Wenn Du jetzt einen Fhemduino und einen SIGNALduino am laufen hast, dann poste doch mal die Logmeldungen von beiden wenn der Rauchmelder auslöst, dann kann ich schauen, was Modul geändert werden müsste.