FHEM+Arduino Firmata via Ethernet+RF 433 Mhz Sender+Baumarkt-Funksteckdosen

[papa]

Auch auf die Gefahr hin, dass ich nerve. Ich finde den Ansatz hier alles nochmal neu aufzurollen nicht wirklich gut.
Wenn das FRM_RC Device also IODev für IT geht, würde das so aussehen.

Code Auswählen Erweitern


define SteckdosenIT FRM_RC 3
attr Steckdose1 IODev FIRMATA

define Steckdose1 IT 1000101000 00 11
attr Steckdose1 IODev SteckdosenIT

define Steckdose2 IT B2
attr Steckdose2 IODev SteckdosenIT


Das IT Modul schickt übrigens immer den TriState-Code zum IODev. Somit kann die gesamte Umrechnung im FRM_RC entfallen.

Wenn der Empfang mit eingebaut werden soll, dann müsste das Define FRM_RC noch einen Parameter für den Empfangspin optional kriegen. Es gabt hier im Forum auch schon mal nen Patch, der den Empfang von IT mittels einer angepassten CUL-Firmware realisiert hat. Vielleicht kriegt man das jetzt alles mal zusammen.

[Christian.]

Wenn der Empfang mit eingebaut werden soll, dann müsste das Define FRM_RC noch einen Parameter für den Empfangspin optional kriegen.

Ich würde stattddessen sowohl Arduino-seitig als auch FHEM-seitig das Senden und den Empfang strikt voneinander trennen, also 2 Arduino-Sketches (die beide in ConfigurableFirmata eingebunden werden können) und zwei getrennte FHEM-Module. Im RCSwitch stehen die Funktionen auch ohne Zusammenhang nebeneinander und teilen sich keine Parameter. In der Praxis wird es Nutzer geben, die nur senden und solche, die nur empfangen. Das wäre dann ganz analog zu FRM_IN und FRM_OUT.

Das IT Modul schickt übrigens immer den TriState-Code zum IODev.

Was müsste so ein IODev-Modul denn leisten, d.h. welche Funktionen oder Attribute gehören da rein?

[papa]

Ich würde stattddessen sowohl Arduino-seitig als auch FHEM-seitig das Senden und den Empfang strikt voneinander trennen, also 2 Arduino-Sketches (die beide in ConfigurableFirmata eingebunden werden können) und zwei getrennte FHEM-Module. Im RCSwitch stehen die Funktionen auch ohne Zusammenhang nebeneinander und teilen sich keine Parameter. In der Praxis wird es Nutzer geben, die nur senden und solche, die nur empfangen. Das wäre dann ganz analog zu FRM_IN und FRM_OUT.

Dann müssten die IT-Devices aber 2 IODevs unterstützen. Eines für das Senden und eines für das Empfangen. Ich glaube so was geht nicht.

Was müsste so ein IODev-Modul denn leisten, d.h. welche Funktionen oder Attribute gehören da rein?

Das ist eine gute Frage - habe noch nie ein Modul entwickelt. Im IT-Code finden sich auf jeden Fall "AttrFn", "GetGn" und "WriteFn" - allerdings über CUL_SimpleWrite().
Da sind halt auch ein paar CUL-spezifische Sachen drin, wie z.B. den rfmode umschalten. Die entsprechenden Writes, könnte ein FRM_RC ja einfach ignorieren.

[Christian.]

Dann müssten die IT-Devices aber 2 IODevs unterstützen. Eines für das Senden und eines für das Empfangen. Ich glaube so was geht nicht.

Meinem Verständnis nach ist 10_IT ein reines Sendemodul - oder täusche ich mich?

[papa]

Meinem Verständnis nach ist 10_IT ein reines Sendemodul - oder täusche ich mich?

http://forum.fhem.de/index.php/topic,14348.0.html hier wurde schon mal der Empfang mit CUL integriert.

[Wzut]

um die RCSwitch-Parameter (protocol, pulseLength, repeatTransmit).

meinst du man muss sie wirklich aus FHEM heraus ändern ?
Bis jetzt ging es doch auch mit den default Werten der RCSwitch.cpp

Eigenschaften des Senders, die für alle Empfänger gemeinsam gelten.

warum ? Wenn du der Meinung bist man müsste sie ändern, dann kann der Anwender auch ebenso gut Mischbetrieb an Geräten haben, d.h. für das eine brauch er andere Werte als für das andere.

In FHEM möchte ich die über eine attr-Deklaration setzen. Wo gehört diese Deklaration hin?

Ja , ich würde einfach die attr Liste um diese Parameter erweitern und mit default Werten vorbesetzen. 
Aber bedenke bitte das dann jedesmal vor dem senden des eigentlichen Codes noch geschaut werden muss welche Parameter an den Arduino müssen. D.h. dann sind jedesmal zwei SysEx fällig, Parameter ändern und Code senden. - wieder unter der Bedienung der Anwender nutzt Mischbetrieb sonst kannst das natürlich einmal beim Init erledigen.

Mehrfach, also an jeder Steckdose?

nach meiner Logik , ja

Ich finde den Ansatz hier alles nochmal neu aufzurollen nicht wirklich gut.

Es steht dir selbstverständlich frei uns (bzw. mir) es  vorzumachen wie es besser geht,
denn mit meinem heutigen Wissenstand kann ich es nicht. Meine eine Baumarksteckdose geht an und aus, d.h. ich bin soweit glücklich
und gebe das Staffelholz gerne weiter.

habe noch nie ein Modul entwickelt

dann ist ja jetzt die beste Gelegenheit damit anzufangen

[papa]

dann ist ja jetzt die beste Gelegenheit damit anzufangen

Leider lassen Job & Familie nicht genügend Zeit für umfangreiche Entwicklungen. Ich sehe allerdings, dass hier viel Zeit und Energie in unterschiedliche Lösungen für IT gesteckt werden. Ich versuche nur, diese zu bündeln und in eine gemeinsame Architektur zu überführen. Das Ganze könnte dann hoffentlich auch mal in das offizielle Update einfließen und damit allen FHEM-Usern zu Gute kommen.

[ntruchsess]

Hallo Ihr,

ich hatte leider ziemlich wenig Zeit die letzten 14 Tage, den Thread habe ich erst gestern genauer gelesen. Finde ich ziemlich cool, wie zügig Ihr das umgesetzt habt!

Das verwendete Sysex-Protokoll sollte man aber noch mal ein bischen überarbeiten, so dass es die RCSwitch-library möglichst vollständing unterstützt - auch wenn das noch nicht alles implementiert ist, aber sonst verbaut man sich (oder anderen) später den Weg. Also nicht einfach eine einezige Funktion der Library unterhalb des Sysex-befehls, sondern darunter noch Subkommandos (senden, configurieren, empfangen...), schaut einfach mal z.B. in die OneWireFirmata.cpp rein, da erkennt man schnell das Prinzip. Bitte macht für das Protokoll ein Proposal im Protocol-repository auf Github (einfach auf Github das Repository clonen und dann das Proposal als neue 'rcswitch.md'-datei per pull-request gegen protocol/master abschicken).

Ich hab mal einen Blick in die Implementierung geworfen, die RCSwitch-library arbeitet empfangsseitig ja über Interrupts und damit (abgesehen von den zum Timing der Sequenzen nicht vermeidbaren delays im µS-Bereich) nicht blockierend und sollte damit gut mit anderen Firmata-Features koexistieren können. (Das ist nicht so selbstverständlich - leider sind viele Libraries nicht dafür gemacht mit anderem code reibungslos parallel laufen zu können). Wenn das Protokoll steht spricht aus meiner Sicht nichts dagegen das zügig in die 'offizielle' ConfigurableFirmata aufzunehmen, damit es seinen offiziell reservierten Pinmode + Sysex-command bekommt.

Analoges auch für die Perl-firmata (Protocol.pm): Da würde ich darum bitten, die Dateien im FHEM-SVN nicht zu ändern, sondern alle Änderungen als Pull-request gegen das perl-firmata Repository auf Github einzusteuern. Es macht keinen Sinn eine 'FHEM'-Spezialversion der Perl-firmata zu pflegen. Wenn man neue Features nicht in das 'offizielle' Firmata-protokoll einsteuert, dann kommt es auch nicht in die Perl-firmata rein. (Was kein Problem wäre - man kann die entsprechenden Aufrufe zum Zusammenbauen und Abschicken des Requests ja auch im FHEM-modul selbst machen).

Änderungen am FRM-code sind da natürlich unkomplizierter - die leben ja nur innerhalb von FHEM... Wobei ich es auch da bevorzugen würde einen pull-request gegen meinen fhem-mirror auf Github zu kriegen bzw. alle, die an FRM und Submodulen mitarbeiten wollen auf diesem Repository berechtigen würde, damit man da vor Veröffendlichung im FHEM-SVN in eigenen Branches unkompliziert zusammenarbeiten kann.
Gerade beim Thema: 'mehrere FRM-Client-Instanzen teilen sich einen Arduino-Pin' besteht da offensichtlich noch Optimierungspotenzial

Gruß,

Norbert

[Wzut]

Dank für die ausführliche Antwort, aber an einem Punkt möchte ich nochmal nachfassen:

Gerade beim Thema: 'mehrere FRM-Client-Instanzen teilen sich einen Arduino-Pin' besteht da offensichtlich noch Optimierungspotenzial

Hier ist eine entscheidende Frage an dich als Autor von 10_FRM.pm offen:
Bist du gewillt in 10_FRM eine "Sonderbehandlung" für Geräte die sich einen Pin teilen einzuführen oder ist dein Standpunkt eher in der Richtung zu sehen "soll doch das Fremdmodul sehen wie es klar kommt" ?

[ntruchsess]

Bist du gewillt in 10_FRM eine "Sonderbehandlung" für Geräte die sich einen Pin teilen einzuführen oder ist dein Standpunkt eher in der Richtung zu sehen "soll doch das Fremdmodul sehen wie es klar kommt" ?

Da bin ich flexibel und für alle sinnvollen Vorschläge offen. 10_FRM ist ja keine 'öffendliche API', wo man alles lieber 3 mal durchdenkt und nach Veröffendlichung kaum noch was ändern kann, weil man die Nutzer nicht kennt. (Das ist ein ganz wesentlicher Unterschied zum 'offiziellen' Firmata-protokoll oder auch der Perl-firmata). Sag einfach was gebraucht wird, oder mach (wenn der code schon steht) entsprechende Pull-requests auf Github um die Details am Code selbst (auf Github kann man sehr schön Kommentare zu jeder code-zeile eines Pull-requests hinzufügen) zu diskutieren.

Gruß,

Norbert

[Christian.]

Finde ich ziemlich cool, wie zügig Ihr das umgesetzt habt!

Danke

Das verwendete Sysex-Protokoll sollte man aber noch mal ein bischen überarbeiten

Keine Sorge, das habe ich bereits getan, ganz analog zu OneWire. Ich stelle mir den Sketch als vollständigen Adapter zu RCSwitch vor. Ich habe zuletzt das Übermitteln der Sende-Parameter implementiert und arbeite jetzt an einer Rückmeldung. Danach möchte ich mich um den Empfang von Daten kümmern.

Bitte macht für das Protokoll ein Proposal auf Github

Git ist Neuland für mich, aber das schaue ich mir an. Ich hatte sowieso vor, dass alles erstmal "über Deinen Tisch" geht - die Firmata-Erweiterung ebenso wie die Perl-Module. Auf diesem Weg ist es sicher am praktischsten.

Gerade beim Thema: 'mehrere FRM-Client-Instanzen teilen sich einen Arduino-Pin' besteht da offensichtlich noch Optimierungspotenzial

Ja, ich finde es prima, dass wir uns hier im Forum darüber austauschen können, bevor jemand von uns viel Arbeit in eine Lösung steckt, die sich hinterher als verbesserungswürdig herausstellt. Ich habe meinen RF-Sender/Empfänger für 2€ (brutto und inkl. Versand!?!) erstanden und ging deshalb davon aus, dass man bei unterschiedlichen Geräten einfach mehrere Pins mit je einem Sender belegt. An eine gemeinsame Nutzung hatte ich überhaupt nicht gedacht. Grundsätzlich bin ich der Meinung von papa, dass man möglichst viel Code gemeinsam nutzen und möglichst wenig doppeln sollte. Andererseits hat Wzut auch Recht, dass im 10_IT-Modul gar nicht so furchtbar viel Logik enthalten ist. Vielleicht finden wir ja gemeinsam eine optimale Lösung.

Ich plane jetzt zunächst, die Arduino-Seite rund zu machen und das dann auf github zu veröffentlichen. Dann können wir uns das ja mal gemeinsam ansehen.

[ntruchsess]

Ich habe meinen RF-Sender/Empfänger für 2€ (brutto und inkl. Versand!?!) erstanden und ging deshalb davon aus, dass man bei unterschiedlichen Geräten einfach mehrere Pins mit je einem Sender belegt. An eine gemeinsame Nutzung hatte ich überhaupt nicht gedacht.

Auch wenn die Teile billig sind: wenn alle auf der gleichen Frequenz laufen wäre das eher kontraproduktiv.

Grundsätzlich bin ich der Meinung von papa, dass man möglichst viel Code gemeinsam nutzen und möglichst wenig doppeln sollte. Andererseits hat Wzut auch Recht, dass im 10_IT-Modul gar nicht so furchtbar viel Logik enthalten ist.

Eine gemeinsame codebasis nutzen bedeutet primär ein gemeinsames Interface zu implementieren. Wie das z.B. bei den plattformübergreifenden I2C-modulen realisiert worden ist. Selbst wenn man nur vergleichsweise wenig logic im 10_IT.pm hat, wenn man das für mehrere Backends nutzen würde, wäre das nicht nur leichter wartbar, sondern auch für die Anwender einfacher verständlich.
Im Grunde genommen bräuchte man für so simple Ein/Ausschalter-module auch noch eine API zwischen dem physikalischen Modul, das mit der Hardware spricht und den logischen - zu schaltenden - Einheiten, die im Prinzip nicht viel mehr als 'set xxx on/off' + SetExtensions verstehen. Das könnte man für alles was über ein physikalisches Gerät mehrere Aktoren an/aus schalten kann (gilt genauso für GPIO-pins am Pi oder FRM_IN/FRM_OUT am Arduino) für den Benutzer komplett vereinheitlichen.

Ich plane jetzt zunächst, die Arduino-Seite rund zu machen und das dann auf github zu veröffentlichen.

Nur keine Scheu. Einfach das Firmata-repository auf Github clonen und einen neuen Branch dafür anlegen (auch wenn der code noch nicht fertig ist). Da kann Dir keiner was kaputtmachen und im besten Fall bekommst du wertvolles Feedback.

Gruß

Norbert

[Christian.]

Das Senden und die zugehörige Konfiguration sind jetzt soweit fertig. Ich habe deshalb auf GitHub Pull-Requests für firmata/protocol (Proposal), firmata/arduino (RCOutputFirmata), ntruchsess/fhem-mirror (20_FRM_RCOUT) und ntruchsess/perl-firmata erstellt. Ist alles immer noch sehr fremd für mich, bin für Kommentare offen.

[ntruchsess]

Hallo Christian,

klappt ja prima mit den pull-requests (ich würde nur einen weniger nichtssagenden nick als 'git-developer' auf github benutzen).
Als erstes müssen wir den pull-request gegen Firamta-configurable_dev mit Jeff Hoeffs abgestimmt bekommen, ich habe ein paar Kommentare rein geschrieben. Die anderen Pull-requests machen wir dann im Nachgang, die sind ja abhängig davon, was bzw. wie da in die Configurablefirmata aufgenommen wird.

Gruß,

Norbert

[ntruchsess]

Hallo Christian,

Ich habe gesehen, Du würdest das RCSwitch-feature (wg. der Problematik mit der Abhängigkeit zur RCSwitch-library) lieber als Example zur ConfigurableFirmata beisteuern. Das ist grundsätzlich mal in Ordnung. Das bedeutet aber auch, dass ich die code-Änderungen an der perl-firmata nicht übernehmen kann (weil nicht 'offizielles' Firmata-protokoll), das müsste dann ins FRM_RC_OUT-modul und einer kleinen Erweiterung des FRM-moduls um einen Sysex-listener gemacht werden. Der Pin-mode und das primäre Sysex-command sollten dann konfigurierbar (natürlich mit zum RCSwitch-example passenden Defaultwerten) gehalten werden.

Mit anderen vorrausichtlich auch nicht so weit benutzten FirmataFeatures wie DHT11-Unterstützung könnte man dann im Prinzip genauso verfahren.

Gruß,

Norbert