Hausbus3: Unterschied zwischen den Versionen
Else (Diskussion | Beiträge) K (→Topics) |
Else (Diskussion | Beiträge) K (→Code: soundserver) |
||
Zeile 75: | Zeile 75: | ||
* [https://github.com/raumzeitlabor/hausbus3-exporters hausbus3-exporters]: Exportiert auf dem Hausbus3 publizierte Sensorwerte zu Cosm und OpenTSDB. | * [https://github.com/raumzeitlabor/hausbus3-exporters hausbus3-exporters]: Exportiert auf dem Hausbus3 publizierte Sensorwerte zu Cosm und OpenTSDB. | ||
* [https://github.com/raumzeitlabor/heizungssteuerung heizungssteuerung]: Heizungssteuerung im Hauptraum. Durch die Nicht-Verfügbarkeit von tiefpunkt.vm.rzl aktuell nur in abgespeckter Version. | * [https://github.com/raumzeitlabor/heizungssteuerung heizungssteuerung]: Heizungssteuerung im Hauptraum. Durch die Nicht-Verfügbarkeit von tiefpunkt.vm.rzl aktuell nur in abgespeckter Version. | ||
=== needed === | |||
* Soundserver, der auf Events reagiert. Es gibt bereits einen simplen [https://github.com/raumzeitlabor/rzl-krachbumms Soundserver], der allerdings nur über HTTP funktioniert. Gewünscht wäre eine modifizierte Version, die sich auf den gesamten /service Tree subscribed (Topic: /service/#) und bei Events auf unserem Datengrab in einem bestimmten Verzeichnis schaut, ob es für das Topic eine gleichnamige Sounddatei gibt, die dann abgespielt wird. Neue Sounds könnte man dann einfach registrieren in dem man Dateien auf dem Datengrab ablegt. | |||
[[Kategorie:Projekt]][[Kategorie:Infrastruktur]] | [[Kategorie:Projekt]][[Kategorie:Infrastruktur]] |
Version vom 7. Juni 2014, 09:50 Uhr
Hausbus3 Release status: experimental [box doku] | |
---|---|
![]() | |
Beschreibung | |
Autor(en) | tiefpunkt |
Letzte Version | v3.0.1 |
Auf besonderen Wunsch wurde aus der kontinuierlichen Weiterentwicklung des Hausbus2 nun der Hausbus3. Er setzt auf ähnlichen Konzepten auf, ergänzt aber viel sinnvolles noch dazu.
Die Kommunikation auf dem Hausbus3 erfolgt via Message Queues, in diesem Falle MQTT. Zusätzlich ist es je nach Implementierung möglich, über HTTP und HTTPS mit kommunizieren, um auch ohne MQTT auf gewissen Dienste direkt zugreifen zu können.
Vorschläge und Kritik am Konzept sind gerne gesehen.
Message Queues
Der Hausbus2 ein Pull-Prinzip vor. Ein Teilnehmer, der über Events oder Sensorwerte benachrichtigt werden möchte, muss aktiv Geräte pollen, um den aktuellen Status zu erfahren, und somit eine eventuelle Änderung mitzubekommen.
Nachteile:
- Geräte müssen bekannt sein, nachträgliches Hinzufügen ist nur schwierig möglich.
- Polling ist doof.
Alternative: Eine Message Queue.
Nach einigen Überlegungen wurde MQTT als Protokoll ausgewählt. Gründe für die Auswahl:
- Lightweight
- Leicht zu implementieren, Libraries für viele Sprachen
- Last-Will-Funktion
- Inaktive Devices bekommen Meldungen an sie, sofern gewünscht, vom Broker gecacht und später nachgereicht.
- Authentifizierung, etc. möglich.
Topics
Es folgt eine Liste von Topics, die momentan auf dem Broker gepublished werden.
- service
- fnordcredit
- transactions - Alle fnordcredit Transaktionen
- status
- presence - Laboranten im Space (retained)
- plug
- $plugname - die jeweilige Steckdose
- state - der aktuelle Zustand (retained)
- power - aktueller Stromverbrauch in W
- consumption
- consumptionTotal
- $plugname - die jeweilige Steckdose
- fnordcredit
Beispiel zum subscriben auf der Kommandozeile (offizieller Client): mosquitto_sub -h infra.rzl -t /service/status/presence
HTTP/HTTPS
HTTP und HTTPS Kommunikation funktionieren fast ähnlich des Hausbus2. WIrd sich aber noch ändern, und dann auch ausführlicher dokumentiert.
Angebundene Geräte
tiefpunkt.vm.rzl
- Hostet den MQTT-Broker (mosquitto)
- hausbus3-exporters. Exportieren Sensordaten zu aktuell Cosm und OpenTSDB
Heizungssteuerung (heizung.rzl)
- Temperatursensoren
- Fensterstatus
infra.rzl
- auf infra.rzl läuft ein MQTT Broker für alle zentralen Dienste
- eventuell sollte man den mit tiefpunkts bridgen (oder ersetzen)
Code
Basis-Implementierung: hausbus3-python
Endpunkte:
- hausbus3-raumstatus: Transferiert den Raumstatus (Hausbus1) auf den Hausbus3. Tut noch nicht.
- hausbus3-exporters: Exportiert auf dem Hausbus3 publizierte Sensorwerte zu Cosm und OpenTSDB.
- heizungssteuerung: Heizungssteuerung im Hauptraum. Durch die Nicht-Verfügbarkeit von tiefpunkt.vm.rzl aktuell nur in abgespeckter Version.
needed
- Soundserver, der auf Events reagiert. Es gibt bereits einen simplen Soundserver, der allerdings nur über HTTP funktioniert. Gewünscht wäre eine modifizierte Version, die sich auf den gesamten /service Tree subscribed (Topic: /service/#) und bei Events auf unserem Datengrab in einem bestimmten Verzeichnis schaut, ob es für das Topic eine gleichnamige Sounddatei gibt, die dann abgespielt wird. Neue Sounds könnte man dann einfach registrieren in dem man Dateien auf dem Datengrab ablegt.