Hausbus3: Unterschied zwischen den Versionen

Aus RaumZeitLabor Wiki
Keine Bearbeitungszusammenfassung
(Status auf beta gesetzt, ist ja im Einsatz)
 
(48 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{ProjektInfoBox
{{ProjektInfoBox
|name        = Hausbus3
|name        = Hausbus3
|status      = experimental
|status      = beta
|image      = RaumZeitLabor - Logo - Schwarz.svg
|image      = RaumZeitLabor - Logo - Schwarz.svg
|description =  
|description =  
|author      = [[Benutzer:Tiefpunkt|tiefpunkt]]
|category    = Infrastruktur
|author      = [[Benutzer:Tiefpunkt|tiefpunkt]], [[Benutzer:Else|else]]
|maintainer  = [[Benutzer:Else|else]]
|username    =  
|username    =  
|version    = v3.0.1
|version    = v3.0.1
Zeile 19: Zeile 21:
Vorschläge und Kritik am Konzept sind gerne gesehen.
Vorschläge und Kritik am Konzept sind gerne gesehen.


== Message Queues ==
== Überlegungen ==
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.
Der [[Hausbus2]] sieht 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:
Nachteile:
Zeile 26: Zeile 28:
* Polling ist doof.
* Polling ist doof.


Alternative: Eine Message Queue.
Alternative: Messages werden von den Endgeräten an einen Server gepusht. Hierfür eignet sich z.B. Pubsub Protokoll.


Nach einigen Überlegungen wurde MQTT als Protokoll ausgewählt. Gründe für die Auswahl:
Nach einigen Überlegungen wurde MQTT als Protokoll ausgewählt. Gründe für die Auswahl:
* Lightweight
* Lightweight, läuft z.B. auch auf Arduinos
* Leicht zu implementieren, Libraries für viele Sprachen
* Leicht zu implementieren, Libraries für viele Sprachen
* Last-Will-Funktion
* Last-Will-Funktion (was passiert wenn Endgerät Verbindung verliert)
* Inaktive Devices bekommen Meldungen an sie, sofern gewünscht, vom Broker gecacht und später nachgereicht.
* bei (Re-)Connect können neue Geräte über das letzte Event informiert werden
* Authentifizierung, etc. möglich.
* Authentifizierung, ACLs etc. möglich.
 
== Low-Cost Devices ==
 
''Es folgen einige Überlegungen, wie man Arduinos etc. günstig an den Broker anbinden kann.''
 
Leider eignet sich MQTT eher schlecht für kostengünstige Endgeräte wie z.B. einfache Mikrocontroller. Da man nicht unbedingt für jeden Sender einen Raspberry Pi o.ä. verschwenden möchte, stellt sich die Frage nach einer günstigen Anbindung an unseren Broker, die keinen Ethernet bzw. TCP Stack benötigt.
 
=== Spannungsversorgung ===
 
Für Low-Cost Devices möchte man eigentlich irgendwas cooleres als ein Steckernetzteil zur Spannungsversorgung. Zum Einen belegt jedes Netzteil eine Steckdose, zum anderen ist es auch schlichtweg ineffizient. [[Benutzer:DancingFo|DancingFo]] und [[Benutzer:Else|Else]] überlegen, eine 24V Spannungsversorgung durch unsere Räume zu ziehen, die von einem Hutschienennetzteil (wie z.B. dem [https://secure.reichelt.de/Schaltnetzteile-fuer-Hut-Schiene/SNT-MW-DR60-24/3/index.html?&ACTION=3&LA=2&ARTICLE=85231&GROUPID=4961&artnr=SNT+MW-DR60-24 SNT MW-DR60-24]) versorgt wird. Da die Leitungslänge recht groß sein wird (und damit auch der Spannungsabfall), nimmt man vermutlich besser 24V.
 
Nachteil von 24V ist, dass die Arduinos nicht mehr direkt an der Strippe betrieben werden können. Es gibt aber einstellbare Spannungswandler für wenig Geld (siehe z.B. [http://www.electrodragon.com/product/lm2596s-adj-dc-dc-small-tiny-adjustable-step-down-module-3-40vin-1-5-35vout/ LM2596S]) mit bis zu 3A, die man entweder zentral je Raum installiert, oder an jedem Arduino (auf einer Basisplatine).
 
=== Kommunikation ===
 
Kabelgebundene Busse wie z.B. CAN oder RS485 haben zwar hohe Reichweiten, allerdings ist der Aufwand für die Verlegung des Kabels relativ hoch, da wir auf jedenfall möglichst an jeder Stelle im Raum Geräte anbinden können möchten. Unabhängig davon sind Abzweigungen nicht so einfach möglich, bzw. nur sehr kurz an der Hauptleitung.
 
Es bietet sich daher eine Funkübertragung an. Als sehr günstig stellen sich die NRF24L01 Funkmodule auf 2.4Ghz Basis heraus (ca. 1-2€ pro Modul). Die Reichweite soll unter normalen Bedingungen bis zu 30M betragen, es gibt allerdings auch eine Funkmodulversion mit rausgeführter Antenne, die eine deutlich höhere Reichweiten erreicht (leicht teurer, aber auch nicht mehr als 3-4€). Libraries für Atmel, Arduino und Linux (Raspberry Pi) gibt es bereits.
 
Man könnte ein NRF24L01 Shield für den Raspberry Pi o.ä. entwerfen, der dann wieder die empfangenen Datenpakete auf den MQTT Broker ausleitet. Hierzu würde dann auch noch ein einfaches Protokoll benötigt.


== Topics ==
== Topics ==
* ''service''
** ''[[fnordcredit]]''
*** ''transactions'' - Alle fnordcredit Transaktionen
** ''status''
*** ''presence'' - Laboranten im Space (retained)
** ''plug''
*** ''$plugname'' - die jeweilige [[Funksteckdosen#Setup|Steckdose]]
**** ''state'' - der aktuelle Zustand (retained)
**** ''power'' - aktueller Stromverbrauch in W
**** ''consumption''
**** ''consumptionTotal''


Beispiel zum subscriben auf der Kommandozeile (offizieller Client): <code>mosquitto_sub -h infra.rzl -t /service/status/presence</code>
Im Mai 2014 haben wir begonnen, die ersten Services mit unserem Broker [[Mate (Server)/infra.rzl|infra.rzl]] zu verbinden. Es folgt eine Liste von Topics, die momentan auf dem Broker gepublished werden.
 
''Legende: F=freigegeben, r=retained, q=QoS, b=blacklisted (Änderungen werden nicht gespeichert)''
 
{| class="wikitable"
! style="font-weight: bold;" | Topic
! style="font-weight: bold;" | F
! style="font-weight: bold;" | R
! style="font-weight: bold;" | Q
! style="font-weight: bold;" | B
! style="font-weight: bold;" | Format
! style="font-weight: bold;" | Thing
! style="font-weight: bold;" | Source
! style="font-weight: bold;" | Kommentare
! style="font-weight: bold;" | Kontakt
|-
| /service/fnordcredit/transactions
| X
|
| 0
| X
| application/json
| [[Fnordcredit]]
| [[Mate (Server)/cashdesk.rzl|cashdesk.rzl]]
| User, Delta
| [[Benutzer:silsha|silsha]]
|-
| /service/mpd/song
| X
|
| 0
|
| application/json
| [[MPD]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| aktueller Track; leeres Objekt, wenn momentan nichts abgespielt wird
|
|-
| /service/mpd/state
|
| X
| 0
|
| application/json
| [[MPD]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Zustand des MPDs. play, pause, stop, offline
|
|-
| /service/mpd/command
|
|
| 0
|
| plain text
| [[MPD]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Befehl an den MPD: next, prev, play, pause or toggle
|
|-
| /service/mpd/error
|
|
| 0
|
| Plain Text
| [[MPD]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Human readable error message for misuse of /service/mpd/command
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/status
| X
| X
| 1
|
| application/json
| [[Raumstatus|Tür]]
| [[Pinpad]]
| Status der Tür (bzw. des Schlosses)
| [[Benutzer:Else|else]]
|-
| /service/status/presence
| X
| X
| 1
| X
| application/json
| [[Raumstatus|Tür]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Identifizierte Laboranten
| [[Benutzer:Else|else]]
|-
| /service/status/devices
| X
|
| 0
|
| application/json
| [[Mate (Server)/unifi.vm.rzl|WLAN]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Anzahl Geräte im WLAN
| [[Benutzer:Else|else]]
|-
| /service/plug/$plugname/state
| X
| X
| 0
|
| application/json
| [[Funksteckdosen|Steckdose]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Zustand der Steckdosen
| [[Benutzer:Else|else]]
|-
| /service/plug/$plugname/power
| X
|
| 0
|
| application/json
| [[Funksteckdosen|Steckdose]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| aktueller Stromverbrauch
| [[Benutzer:Else|else]]
|-
| /service/plug/$plugname/consumption
| X
|
| 0
|
| application/json
| [[Funksteckdosen|Steckdose]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| ''?''
| [[Benutzer:Else|else]]
|-
| /service/plug/$plugname/consumptionTotal
| X
|
| 0
|
| application/json
| [[Funksteckdosen|Steckdose]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| ''?''
| [[Benutzer:Else|else]]
|-
| /service/ping/displayText
|
|
| 0
|
| application/json
| [[Pingie Pie|Ping+]]
| egal
| ''Die Payload wird als Text auf dem Display angezeigt. In Node Red konfiguriert. Beispiel: <code>mosquitto_pub -h infra.rzl -t /service/ping/displayText -m "hallo =^.^="</code>''
| [[Benutzer:Felicitus|Drachenkatze]]
|-
| /service/ping/rundumleuchte
|
|
| 0
|
| application/json
| [[Pingie Pie|Ping+]]
| egal
| ''Schaltet die Rundleuchte an und nach 2 Sekunden wieder aus. Beispiel: <code>mosquitto_pub -h infra.rzl -t /service/ping/rundumleuchte -m ""</code>''
| [[Benutzer:Felicitus|Drachenkatze]]
|-
| stat/sonoff/POWER
|
|
| 0
|
| application/json
| [[Pingie Pie|Ping+]]
| egal
| ''Enthält den Zustand des Grobhandtasters. Beispiel: <code>mosquitto_sub -h infra.rzl -t stat/sonoff/POWER </code>''
| [[Benutzer:Felicitus|Drachenkatze]]
|-
| /service/heizung/temp/$sensor
|
| X
| 0
|
| xx.x in °C
| [[Heizungssteuerung]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Fragt via node-red Minütlich die REST-API von heizung.rzl ab und pusht MQTT
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/esper/afba40/socket/set
|
|
| 0
|
| 0 oder 1
| [[Funksteckdosen]]
|
| command topic des Fliegenbratgeräts
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/esper/afba40/socket
|
| X
| 0
|
| 0 oder 1
| [[Funksteckdosen]]
|
| state topic des Fliegenbratgeräts
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/esper/afba45/pulse/pulse
|
|
| 0
|
| ASCII An-Zeit in ms
| [[Funksteckdosen]]
|
| command topic des Alarms
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/esper/afba45/pulse/triggered
|
|
| 0
|
| ASCII An-Zeit in ms
| [[Funksteckdosen]]
|
| feedback topic des Alarms
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/onkyo/#
|
|
| 0
|
|
| [[VHS]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| [https://github.com/owagner/onkyo2mqtt Onkyo-MQTT-Bridge]
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/onkyo/status/#
|
| X
| 0
|
| (mostly) application/json
| [[VHS]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Statusinformationen des Onkyos
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/openhab/out/$item/state
|
| X
| 0
|
| ON or OFF
| [[Funksteckdosen]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Statusmeldungen des OpenHAB (An/Aus/Stromverbrauch)
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/openhab/in/$item/command
|
|
| 0
|
| ON or OFF
| [[Funksteckdosen]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Kommandos an das OpenHAB
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /artnet/push
|
|
| 0
|
| green, purple, red, yellow or cycle-random
|
| [[Mate (Server)/s1lvester.vm.rzl|s1lvester.vm.rzl]]
| Kommandos an die DMX-Lampen auf [[Tardis#Tardis1|Tardis 1]]
| [[Benutzer:S1lvester|S1lvester]]
|-
| /artnet/state
|
| X
| 0
|
| green, purple, red, yellow or cycle-random
|
| [[Mate (Server)/s1lvester.vm.rzl|s1lvester.vm.rzl]]
| Status der DMX-Lampen auf [[Tardis#Tardis1|Tardis 1]]
| [[Benutzer:S1lvester|S1lvester]]
|-
| /heartbeat
|
|
| 0
|
| (leer)
| [[Funksteckdosen]]
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Minütliche leere Nachricht als Watchdog-Reset für die WLAN-[[Funksteckdosen]]
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/ultimaker/job
|
| X
| 0
|
| application/json
| [[Ultimak3r]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Siehe [http://ultimaker.rzl/docs/api/#!/PrintJob/get_print_job]
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/ultimaker/printer
|
| X
| 0
|
| application/json
| [[Ultimak3r]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Siehe [http://ultimaker.rzl/docs/api/#!/Printer/get_printer]
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/ultimaker/state
|
| X
| 0
|
| Plain Text
| [[Ultimak3r]]
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| printing, pausing, paused, resuming, pre_print, post_print, wait_cleanup, booting, idle, error, maintenance or unreachable
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/beamer/state
|
| X
| 0
|
| Plain Text
| Beamer
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| START_UP, unknown, START_UP_LAMP, POWER_ON, COOLING, COOLING2, STANDBY or offline
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/beamer/command
|
|
| 0
|
| Plain Text
| Beamer
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| ON, 1, OFF or 0
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/beamer/error
|
|
| 0
|
| Plain Text
| Beamer
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Human readable error message for misuse of /service/beamer/command
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/heimautomatisierung
|
| X
| 0
|
| ON or OFF
|
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Heimautomatisierungsstatus (normal ON bei Raum auf, OFF bei Raum zu, aber mit 10 Sekunden Verzögerung und Dämpfung bei schnell öffnendem/schließenden Raum)
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/nebenraum-power
|
| X
| 0
|
| ON or OFF
|
| [[Mate (Server)/ranlvor.vm.rzl|ranlvor.vm.rzl]]
| Gibt an ob [[EdgeSwitch_PoE_24]] pingt und damit ob der Strom im Nebenraum freigeschaltet ist
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/deko
|
| X
| 0
|
| ON or OFF
|
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Status des Dekobemodus. Schaltet bei Golden Hour Abends ein, bei Sonnenaufgang aus. Sollte bei Raumstatus Closed ignoriert werden.
| [[Benutzer:Ranlvor|Ranlvor]]
|-
| /service/deko/set
|
|
| 0
|
| ON or OFF
|
| [[Mate (Server)/infra.rzl|infra.rzl]]
| Command-Topic für /service/deko
| [[Benutzer:Ranlvor|Ranlvor]]
|}
 
Beispiel zum Subscriben auf der Kommandozeile (offizieller Client):


== HTTP/HTTPS ==
<pre>mosquitto_sub -h infra.rzl -t /service/status/presence</pre>
HTTP und HTTPS Kommunikation funktionieren fast ähnlich des [[Hausbus2]]. WIrd sich aber noch ändern, und dann auch ausführlicher dokumentiert.


== Angebundene Geräte ==
== Angebundene Geräte ==
=== [[Mate (Server)/tiefpunkt.vm.rzl|tiefpunkt.vm.rzl]] ===
 
==== [[Mate (Server)/tiefpunkt.vm.rzl|tiefpunkt.vm.rzl]] ====
 
* Hostet den MQTT-Broker (mosquitto)
* Hostet den MQTT-Broker (mosquitto)
* hausbus3-exporters. Exportieren Sensordaten zu aktuell Cosm und OpenTSDB
* hausbus3-exporters. Exportieren Sensordaten zu aktuell Cosm und OpenTSDB


=== [[Heizungssteuerung]] (heizung.rzl) ===
''(keine Gewährleistung, ob das noch aktuell ist)''
 
==== [[Heizungssteuerung]] (heizung.rzl) ====
 
* Temperatursensoren
* Temperatursensoren
* Fensterstatus
* Fensterstatus


=== [[Mate (server)/infra.rzl|infra.rzl]] ===
== Broker ==
 
==== [[Mate (Server)/infra.rzl|infra.rzl]] ====
 
* auf infra.rzl läuft ein MQTT Broker für alle zentralen Dienste
* auf infra.rzl läuft ein MQTT Broker für alle zentralen Dienste
* eventuell sollte man den mit tiefpunkts bridgen (oder ersetzen)
* '''TODO:''' eventuell zusätzlich noch mit tiefpunkts bridgen (oder ersetzen)
 
==== premium.rzl ====
 
* unsere externe VM. '''Bridge''' auf infra.rzl (keep-alive 10 Sekunden, automatischer Reconnect)
* bridged den gesamten Tree (#) mit QoS Level 2, ''read-only''
* lauscht nur auf internem loopback
 
==== [[Mate (Server)/tiefpunkt.vm.rzl|tiefpunkt.vm.rzl]] ====
* siehe ''Angebundene Geräte''
 
== Regelframework ==
 
Wir sind noch auf der Suche nach einem geeigneten Regelframework (ähnlich IFFT). Momentan experimentieren wir mit [http://nodered.org Node-Red], einem Daemon mit Webinterface vom IBM. Dieser kann [http://infra.rzl:1880/ hier] erreicht werden, und tut momentan folgendes:
 
* Veröffentlichung des Raumstatus auf @raumzeitstatus


== Code ==
== Code ==
Zeile 74: Zeile 531:
* [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.


[[Kategorie:Projekt]][[Kategorie:Infrastruktur]]
=== 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.

Aktuelle Version vom 4. Februar 2020, 18:18 Uhr

         
Hausbus3

Release status: beta [box doku]

Beschreibung
Kategorie  Infrastruktur
Autor(en)  tiefpunkt, else
Verantwortliche(r)  else
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.

Überlegungen

Der Hausbus2 sieht 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: Messages werden von den Endgeräten an einen Server gepusht. Hierfür eignet sich z.B. Pubsub Protokoll.

Nach einigen Überlegungen wurde MQTT als Protokoll ausgewählt. Gründe für die Auswahl:

  • Lightweight, läuft z.B. auch auf Arduinos
  • Leicht zu implementieren, Libraries für viele Sprachen
  • Last-Will-Funktion (was passiert wenn Endgerät Verbindung verliert)
  • bei (Re-)Connect können neue Geräte über das letzte Event informiert werden
  • Authentifizierung, ACLs etc. möglich.

Low-Cost Devices

Es folgen einige Überlegungen, wie man Arduinos etc. günstig an den Broker anbinden kann.

Leider eignet sich MQTT eher schlecht für kostengünstige Endgeräte wie z.B. einfache Mikrocontroller. Da man nicht unbedingt für jeden Sender einen Raspberry Pi o.ä. verschwenden möchte, stellt sich die Frage nach einer günstigen Anbindung an unseren Broker, die keinen Ethernet bzw. TCP Stack benötigt.

Spannungsversorgung

Für Low-Cost Devices möchte man eigentlich irgendwas cooleres als ein Steckernetzteil zur Spannungsversorgung. Zum Einen belegt jedes Netzteil eine Steckdose, zum anderen ist es auch schlichtweg ineffizient. DancingFo und Else überlegen, eine 24V Spannungsversorgung durch unsere Räume zu ziehen, die von einem Hutschienennetzteil (wie z.B. dem SNT MW-DR60-24) versorgt wird. Da die Leitungslänge recht groß sein wird (und damit auch der Spannungsabfall), nimmt man vermutlich besser 24V.

Nachteil von 24V ist, dass die Arduinos nicht mehr direkt an der Strippe betrieben werden können. Es gibt aber einstellbare Spannungswandler für wenig Geld (siehe z.B. LM2596S) mit bis zu 3A, die man entweder zentral je Raum installiert, oder an jedem Arduino (auf einer Basisplatine).

Kommunikation

Kabelgebundene Busse wie z.B. CAN oder RS485 haben zwar hohe Reichweiten, allerdings ist der Aufwand für die Verlegung des Kabels relativ hoch, da wir auf jedenfall möglichst an jeder Stelle im Raum Geräte anbinden können möchten. Unabhängig davon sind Abzweigungen nicht so einfach möglich, bzw. nur sehr kurz an der Hauptleitung.

Es bietet sich daher eine Funkübertragung an. Als sehr günstig stellen sich die NRF24L01 Funkmodule auf 2.4Ghz Basis heraus (ca. 1-2€ pro Modul). Die Reichweite soll unter normalen Bedingungen bis zu 30M betragen, es gibt allerdings auch eine Funkmodulversion mit rausgeführter Antenne, die eine deutlich höhere Reichweiten erreicht (leicht teurer, aber auch nicht mehr als 3-4€). Libraries für Atmel, Arduino und Linux (Raspberry Pi) gibt es bereits.

Man könnte ein NRF24L01 Shield für den Raspberry Pi o.ä. entwerfen, der dann wieder die empfangenen Datenpakete auf den MQTT Broker ausleitet. Hierzu würde dann auch noch ein einfaches Protokoll benötigt.

Topics

Im Mai 2014 haben wir begonnen, die ersten Services mit unserem Broker infra.rzl zu verbinden. Es folgt eine Liste von Topics, die momentan auf dem Broker gepublished werden.

Legende: F=freigegeben, r=retained, q=QoS, b=blacklisted (Änderungen werden nicht gespeichert)

Topic F R Q B Format Thing Source Kommentare Kontakt
/service/fnordcredit/transactions X 0 X application/json Fnordcredit cashdesk.rzl User, Delta silsha
/service/mpd/song X 0 application/json MPD ranlvor.vm.rzl aktueller Track; leeres Objekt, wenn momentan nichts abgespielt wird
/service/mpd/state X 0 application/json MPD ranlvor.vm.rzl Zustand des MPDs. play, pause, stop, offline
/service/mpd/command 0 plain text MPD ranlvor.vm.rzl Befehl an den MPD: next, prev, play, pause or toggle
/service/mpd/error 0 Plain Text MPD ranlvor.vm.rzl Human readable error message for misuse of /service/mpd/command Ranlvor
/service/status X X 1 application/json Tür Pinpad Status der Tür (bzw. des Schlosses) else
/service/status/presence X X 1 X application/json Tür infra.rzl Identifizierte Laboranten else
/service/status/devices X 0 application/json WLAN infra.rzl Anzahl Geräte im WLAN else
/service/plug/$plugname/state X X 0 application/json Steckdose infra.rzl Zustand der Steckdosen else
/service/plug/$plugname/power X 0 application/json Steckdose infra.rzl aktueller Stromverbrauch else
/service/plug/$plugname/consumption X 0 application/json Steckdose infra.rzl ? else
/service/plug/$plugname/consumptionTotal X 0 application/json Steckdose infra.rzl ? else
/service/ping/displayText 0 application/json Ping+ egal Die Payload wird als Text auf dem Display angezeigt. In Node Red konfiguriert. Beispiel: mosquitto_pub -h infra.rzl -t /service/ping/displayText -m "hallo =^.^=" Drachenkatze
/service/ping/rundumleuchte 0 application/json Ping+ egal Schaltet die Rundleuchte an und nach 2 Sekunden wieder aus. Beispiel: mosquitto_pub -h infra.rzl -t /service/ping/rundumleuchte -m "" Drachenkatze
stat/sonoff/POWER 0 application/json Ping+ egal Enthält den Zustand des Grobhandtasters. Beispiel: mosquitto_sub -h infra.rzl -t stat/sonoff/POWER Drachenkatze
/service/heizung/temp/$sensor X 0 xx.x in °C Heizungssteuerung infra.rzl Fragt via node-red Minütlich die REST-API von heizung.rzl ab und pusht MQTT Ranlvor
/service/esper/afba40/socket/set 0 0 oder 1 Funksteckdosen command topic des Fliegenbratgeräts Ranlvor
/service/esper/afba40/socket X 0 0 oder 1 Funksteckdosen state topic des Fliegenbratgeräts Ranlvor
/service/esper/afba45/pulse/pulse 0 ASCII An-Zeit in ms Funksteckdosen command topic des Alarms Ranlvor
/service/esper/afba45/pulse/triggered 0 ASCII An-Zeit in ms Funksteckdosen feedback topic des Alarms Ranlvor
/service/onkyo/# 0 VHS ranlvor.vm.rzl Onkyo-MQTT-Bridge Ranlvor
/service/onkyo/status/# X 0 (mostly) application/json VHS ranlvor.vm.rzl Statusinformationen des Onkyos Ranlvor
/service/openhab/out/$item/state X 0 ON or OFF Funksteckdosen infra.rzl Statusmeldungen des OpenHAB (An/Aus/Stromverbrauch) Ranlvor
/service/openhab/in/$item/command 0 ON or OFF Funksteckdosen infra.rzl Kommandos an das OpenHAB Ranlvor
/artnet/push 0 green, purple, red, yellow or cycle-random s1lvester.vm.rzl Kommandos an die DMX-Lampen auf Tardis 1 S1lvester
/artnet/state X 0 green, purple, red, yellow or cycle-random s1lvester.vm.rzl Status der DMX-Lampen auf Tardis 1 S1lvester
/heartbeat 0 (leer) Funksteckdosen infra.rzl Minütliche leere Nachricht als Watchdog-Reset für die WLAN-Funksteckdosen Ranlvor
/service/ultimaker/job X 0 application/json Ultimak3r ranlvor.vm.rzl Siehe [1] Ranlvor
/service/ultimaker/printer X 0 application/json Ultimak3r ranlvor.vm.rzl Siehe [2] Ranlvor
/service/ultimaker/state X 0 Plain Text Ultimak3r ranlvor.vm.rzl printing, pausing, paused, resuming, pre_print, post_print, wait_cleanup, booting, idle, error, maintenance or unreachable Ranlvor
/service/beamer/state X 0 Plain Text Beamer ranlvor.vm.rzl START_UP, unknown, START_UP_LAMP, POWER_ON, COOLING, COOLING2, STANDBY or offline Ranlvor
/service/beamer/command 0 Plain Text Beamer ranlvor.vm.rzl ON, 1, OFF or 0 Ranlvor
/service/beamer/error 0 Plain Text Beamer ranlvor.vm.rzl Human readable error message for misuse of /service/beamer/command Ranlvor
/service/heimautomatisierung X 0 ON or OFF infra.rzl Heimautomatisierungsstatus (normal ON bei Raum auf, OFF bei Raum zu, aber mit 10 Sekunden Verzögerung und Dämpfung bei schnell öffnendem/schließenden Raum) Ranlvor
/service/nebenraum-power X 0 ON or OFF ranlvor.vm.rzl Gibt an ob EdgeSwitch_PoE_24 pingt und damit ob der Strom im Nebenraum freigeschaltet ist Ranlvor
/service/deko X 0 ON or OFF infra.rzl Status des Dekobemodus. Schaltet bei Golden Hour Abends ein, bei Sonnenaufgang aus. Sollte bei Raumstatus Closed ignoriert werden. Ranlvor
/service/deko/set 0 ON or OFF infra.rzl Command-Topic für /service/deko Ranlvor

Beispiel zum Subscriben auf der Kommandozeile (offizieller Client): 

mosquitto_sub -h infra.rzl -t /service/status/presence

Angebundene Geräte

tiefpunkt.vm.rzl

  • Hostet den MQTT-Broker (mosquitto)
  • hausbus3-exporters. Exportieren Sensordaten zu aktuell Cosm und OpenTSDB

(keine Gewährleistung, ob das noch aktuell ist)

Heizungssteuerung (heizung.rzl)

  • Temperatursensoren
  • Fensterstatus

Broker

infra.rzl

  • auf infra.rzl läuft ein MQTT Broker für alle zentralen Dienste
  • TODO: eventuell zusätzlich noch mit tiefpunkts bridgen (oder ersetzen)

premium.rzl

  • unsere externe VM. Bridge auf infra.rzl (keep-alive 10 Sekunden, automatischer Reconnect)
  • bridged den gesamten Tree (#) mit QoS Level 2, read-only
  • lauscht nur auf internem loopback

tiefpunkt.vm.rzl

  • siehe Angebundene Geräte

Regelframework

Wir sind noch auf der Suche nach einem geeigneten Regelframework (ähnlich IFFT). Momentan experimentieren wir mit Node-Red, einem Daemon mit Webinterface vom IBM. Dieser kann hier erreicht werden, und tut momentan folgendes:

  • Veröffentlichung des Raumstatus auf @raumzeitstatus

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.
Abgerufen von „https://wiki.raumzeitlabor.de/index.php?title=Hausbus3&oldid=15190“