Frage OFM-InternetWeatherModule

[K1rk]

Hi,
Mit Spannung verfolge ich seit einiger Zeit das Thema OpenKNX und freue mich auch schon auf die neuen REG1 Geräte auf ESP32 Basis.
Sobald die bestellbar sind, werd ich auch das ein oder andere Gerät mein Eigen nennen

Ich suche nun schon länger eine Möglichkeit Wetterdaten in KNX direkt zu haben ohne tief in die Tasche greifen zu müssen für eine Wetterstation.
Zumal mir ca. Werte völlig reichen. Ich brauche die Wetterdaten hauptsächlich für die Automatische Beschattung.
Bis heute Morgen hätte ich den Weg - Node-Red - beschritten, als ich das oben genannte Modul entdeckt habe. Sofern ich es richtig verstanden habe wird hier genau das gemacht was ich mit Node-Red vorhatte.

Nun zu meiner Frage: (ich habe ja noch keine Hardware ums zu testen)
Wie kann ich mir das vorstellen? Ich nehme ein bspw. REG1 Gerät und flashe die Firmware OFM-InternetWeatherModule?
Hat das Modul dann ein eigenes Applikationsprogramm mit bestenfalls auch Logik-Vernüpfungen (also zB. abends Jalousien zu)? Darüber finde ich nämlich nichts.

Danke für eure Antwort!

[Ing-Dom]

Ich nehme ein bspw. REG1 Gerät und flashe die Firmware OFM-InternetWeatherModule?

nein. OFM-InternetWeatherModule ist ein OpenKNX Function Module, keine singulär laufende Applikation.
Es ist zB im OAM-InternetServices (Application Module) eingebunden - zusammen auch mit Logik und weiteren OFMs.
ShutterControll fehlt aber - wäre aber ggf schon sinnvoll - keine Ahnung was Michael mgeramb hier plant.
OAM-InternetServices wird sicher eine der ersten Applikationen sein, die auf der neuen ESP HW (REG1-LAN-TP-Base) laufen..

[traxanos]

K1rk magst du bei dir die PNs (Private Nachrichten) einschalten.

[K1rk]

Danke für die schnelle Aufklärung.
Daher das A und F. Und das OAM Internet Services ist dann halt wie das Logik Modul, IP Router, etc. eine FW für ein Gerät (FW+knxprod). Hab ichs jetzt? Sry... ich hab versucht das aus dem Wiki zu lesen aber irgendwie hab ichs dort offensichtlich nicht gefunden (oder nicht richtig in Zusammenhang bringen können)

Ja die Funktionalitäten die bspw. eine Elsner Wetterstation mit sich bringen hätten schon Charme und würden die Wetterdaten natürlich noch sexier machen. mgeramb *liebschau*

Edit: passt hier nicht aber, wenn ich schon nicht am durchblicken bin: warum gibt eines eine OFM Smarthomebridge UND OAM Smarthomebrigde?

Ich hoffe ich kann dann etwas Licht ins Dunkel bringen sobald ich HW habe um Dinge zu testen.

K1rk magst du bei dir die PNs (Private Nachrichten) einschalten.

done

[Ing-Dom]

aber irgendwie hab ichs dort offensichtlich nicht gefunden

https://github.com/OpenKNX/OpenKNX/w...ftware-modules

warum gibt eines eine OFM Smarthomebridge UND OAM Smarthomebrigde?

Wir versuchen möglichst jede Funktionalität modular, also wiederverwendbar als OFM auszuführen. So kkönnte zB ein "OAM-Multi-Gateway" ggf auch ein paar Kanäle der Smarthmebridge mit nehmen. Gerade am anfang fängt man aber mal eher reduziert an und hat eine dezidierte Applikation..
Es gibt auch ein OFM-Logic (wird fast in jeder OAM Applikation verwendet) und ein OAM-Logic..

[mumpf]

Der Punkt ist, dass die ETS exakt eine Applikation haben will pro Gerät (hat bei uns den Präfix OAM). Wir wollen aber die Möglichkeit haben, die Funktionen von verschiedenen (virtuellen) Applikationen in eine ETS-Applikation zu packen. Deshalb haben wir das Konzept der (Funktions-)Module, die wir mit OFM anfangen lassen.

Es kann jetzt so was geben wie

• OAM-Logic mit OFM-Logic - einfach das Logikmodul als eigene Applikation
• OAM-Fingerprint mit OFM-Logic - Das ist der (derzeit noch nicht modulare) Fingerprint mit dem Logikmodul
• OAM-Presence mit OFM-Presence, OFM-Logic - Präsenzapplikation mit dem (eigenen) Präsenzmodul und Logikmodul
• OAM-Sensor mit OFM-Sensor, OFM-Presence, OFM-Button, OFM-BinaryInput, OFM-Logic - selbsterklärend

Im Prinzip kann damit auf einer Hardware etwas laufen, was sonst viele Geräte erforderlich machen würde. Die Grenzen müssen auch immer klar sein: Nur weil die Software z.B. zulässt, 8 Sensoren an eine Hardware anzuschließen, heißt das noch lange nicht, dass die 8 Sensoren gleichzeitig an der Hardware laufen können.

Gruß, Waldemar

[K1rk]

Vielen Dank euch!
Ing-Dom: hab im Github Wiki nicht gecheckt, dass die Überschriften links sind. Somit dachte ich alles gelesen zu haben, was aber ein Trugschluss war.
Dank an traxanos - ist viel übersichtlicher.
und dank auch an mumpf für die einleuchtende Erklärung. Das "fixt" mich noch mehr an!

Weil du schreibst: die SW kann zulassen, dass man 8 Sensoren anschließt - die HW nicht. Klar soweit. Aber rein auf die physischen Anschlüsse bezogen oder auch auf die (Rechen-)Leistung?
Worauf ich hinauswill: Gibt es zahlenmäßig Grenzen bei den OFMs? Also auf dein OAM Sensor Beispiel bezogen: könnte dann noch 20 weitere Funktionen installiert werden?

Und noch eine letzte Frage: bespielt man die OFMs gemeinsam mit der OAM (also bau ich mir die in der Toolbox zusammen und flashe dann) oder installiert man die nach? Ich nehme an, dass sich die Fragen mit dem Erhalt der HW bzw. sobald ich damit spielen kann dann ohnehin aufklären

Nochmal: Hammer Projekt! Ich überlege wie ich mich da sinnvoll einbringen kann.

[traxanos]

Nein ein OFM ist immer Teil einer OAM. Ich schicke dir noch einen Link.

[traxanos]

Gibt es zahlenmäßig Grenzen bei den OFMs?

Die Idee ist was anderes. Du hast eine HW die 2 Binäreingänge hat. Wenn du jetzt eine generische Applikation hast die auch auf einer anderen HW mit 4 Binäreingänge laufen soll, dann wird die Appliaktion mit 4 Binäreingänge in der ETS gebaut und auf deiner HW mit nur 2 BEs funktionieren halt nur die ersten beiden.

Das Sensormodul ist konzeptionell aktuell auf je einen Sensor gebaut worden. Daher gibt es für das SEN-UP auch eine andere Appliaktion mit anderem Schwerpunkt

[Ing-Dom]

Und noch eine letzte Frage: bespielt man die OFMs gemeinsam mit der OAM (also bau ich mir die in der Toolbox zusammen und flashe dann) oder installiert man die nach?

Nein - die Aggregation von Modulen zu Applikationen passiert bei der Entwicklung. D.h.der OAM-Entwickler legt fest, wieviel Kanäle von welchen Modulen, ggf mit welchen Optionen integriert werden.
Da wir OpenSource sind, kannst du das natürlich auch selbst, aber dafür muss man schon tief einsteigen und braucht auch Spezialwissen.

[mgeramb]

keine Ahnung was Michael mgeramb hier plant.

Ursprünglich hatte ich wirklich geplant ein OAM zu bauen wo alles drinnen ist was man in einem Raum so braucht. Aktuell denke ich aber, das es damit nichts wird weil die Firmware einfach zu groß wird und nicht mehr Platz hat im flash. Deshalb wird es wohl weiterhin eher spezialisierte OAM's brauche. Aber wenn jemand sich z.B. die SmartHomebridge mit einer einzelnen anderen OFM kombinieren will, besteht die Möglichkeit dazu.

Und noch eine letzte Frage: bespielt man die OFMs gemeinsam mit der OAM

Leider ist das nicht so einfach. Man braucht schon Basis-Entwicklungskenntnisse und einiges OpenKNX Know-How um eine eigene OAM mit frei gewählten OFM's zu bauen.

Deshalb erstmal ausschaue nach den OAM's machen und suchen wo die OFM's drinnen sind die man haben will.
Zusammen mit der ESP HW wird es jedenfalls erste Betas der SmartHomebrige (OAM-SmartHomeBridge) , des Wetterdienstes (OAM-InternetServices) und Sonos (OAM-Sonos) geben. Aber ein wenig Geduld braucht das noch. Wobei das OAM-InternetServices die einzige Firmware wird, die auch noch auf der derzeitigen RP2040 basierenden Hardware laufen wird. Die anderen brauchen zwingend den ESP32.

[K1rk]

Das hab ich aus dem Wiki nicht so rauslesen können. Besten Dank nochmal für die DAU Erklärung.
Freu mich auf erste Tests.

[mumpf]

Aber rein auf die physischen Anschlüsse bezogen oder auch auf die (Rechen-)Leistung?

Grob betrachtet gibt es 3 begrenzende Faktoren:

1. Die physikalischen Anschlußmöglichkeiten: Wie traxanos schon sagte, wenn es nur 2 Binäreingänge gibt, und die Firmware 4 anbietet (weil generisch geschrieben für unterschiedliche Hardware), dann wird man nicht 4 bekommen, egal wie man sich querstellt . Aber da bieten wir auch - wenn es Sinn macht - durch virtuelle Kanäle eine Abstraktion an. Der Präsenzmelder kann die Präsenz- und Helligkeitsinfo direkt von der Hardware oder auch über den Bus erhalten. Oder das Tastermodul, dass seine Tastimpulse vom Binäreingang oder über den Bus erhalten kann.
2. Der Speicher/Rechenkapazität/ETS-Applikationsgröße: Wenn es das nicht gäbe, würden wir eine große Applikation schreiben für alles , und man würde nur am Anfang auswählen, das und das und das will ich haben. Wird es (leider) so nicht geben.
3. Energie (also der Busstrom, den wir "ziehen" dürfen). Mein Sensormodul könnte durchaus 6 verschiedene Sensoren abfragen, aber es gibt derzeit keine Hardware von uns, die diese Energiemenge liefern könnte. Das "größte" ist derzeit der Präsenz-Multisensor, der HF-PM, Helligkeit, VOC und CO2 kann. Versuchst Du das selbe mit dem REG1, wird er dauernd ausfallen.

Und der Software-Baukasten, wie Du ihn Dir vorstellst, wäre nett (Enduser baut sich mit ein paar Clicks das zusammen, was er braucht), aber da gibt es einfach zu viele Probleme zu lösen. Wir haben einfach nur einen Microcontroller und die ETS. Beide erlauben keine beliebige Flexibilität, in diesem Fall ist sogar die ETS das größere Problem.

Gruß, Waldemar

[traxanos]

das ist genau das was ich ihm gerade auch per pn geschrieben hatte. die ets ist hier das haupt problem weil es auf fertige produkte mit festemfunktionsumfang designt wurde.

[Noschvie]

den Weg - Node-Red - beschritten

du suchst eine virtuelle Wetterstation, die auf der einen Seite KNX bespielt und auf der anderen Seite sich das Wetter aus dem Internet besorgt. Warum gibt’s sowas noch nicht? Was braucht‘s denn dazu? Eine NanoBCU und einen ESP32 ?