Diskussion:Hausbus2

Sprechendere Pfade

Mein Vorschlag wäre, die Pfade ein wenig sprechender zu machen, und die API in einen Unterordner zu schieben. So kann man auch eine Art Web-Interface auf den Hausbus2-Nodes implementieren, ohne der API in die Quere zu kommen. Konkret würde das heißen, um mal die Beispiele zu nutzen:

• /api/common/state
• /api/common/state/pinpad.door
• /api/common/reboot
• /api/unlock_door
• /api/look_door

Wie seht ihr das? --Tiefpunkt 09:22, 23. Jan. 2012 (CET)

• Halte ich nicht für nötig. In allen modernen Sprachen sind Routen/Endpunkte frei definierbar, eine Notwendigkeit für einen "Unterordner" gibt es nicht. In Anbetracht der Tatsache, dass die Server außer der API nichts anderes anbieten (oder höchstens eine index.html mit Hilfe) ist das auch ziemlich redundant. Der Pfad _ ist so gewählt, dass er "privat" impliziert (für Python/Perl-Programmierer z.B.) und mit keinem anderen, "sprechenden" Endpunkt kollidiert. --sECuRE 19:31, 16. Apr. 2012 (CEST)

Proposed Updates 18. Dezember 2012

Ich hab im Python-Module eine relativ wichtige Änderung gemacht: Die Werte werden vom Status-Endpunkt nun nicht mehr als flacher JSON ausgegeben, sondern verschachtelt. Das macht IMHO wesentlich mehr Sinn als die aktuelle Spezifikation, die die Unterteilung im jeweiligen Key durch den Punkt vornimmt. Heißt im Beispiel von vorne nun also nicht mehr:

{"pinpad.door": "locked",
 "pinpad.lastsync": 1321819942,
 "pinpad.wrongpins": 3,
 "pinpad.msg": "Willkommen im RZL"}

Sondern:

{ "pinpad": {
   "door": "locked",
   "lastsync": 1321819942,
   "wrongpins": 3,
   "msg": "Willkommen im RZL"
  }
}

Das vereinfacht das Parsen des JSONs ungemein. Gibt es da Einwände gegen?

Ansonsten wäre ich dafür, MQTT zur Propagierung von Events zu nutzen. Eine Message Queue ist an der Stelle durchaus sinnvoll, um die Busendgeräte nicht unnötig durch Polling zu belasten. Warum MQTT?

• Simpel
• Brauch extrem wenig Bandbreite
• Implementierung in vielen Sprachen verfügbar
• Kann Nachrichten persistieren
• Kann Authentifizierung und Berechtigungen und so
• Erlaubt einen "last will", eine Meldung, wenn ein Client abschmiert

Nachteil: Wir brauchen einen zentralen Broker. Aber das kann man IMHO verschmerzen.

--Tiefpunkt (Diskussion) 00:06, 18. Dez. 2012 (CET)

• Inwiefern soll sich da jetzt das parsen vereinfacht haben? IMHO ist die Trennung mit Punkt die einfachere Variante zum Parsen ;-) Bzgl. MQTT: Klingt interessant. Könntest du, wenn du mal wieder da bist, einen Vortrag drüber halten?

• • Nun, der Status hat ja hierarchische Struktur. Beim Pinpad vllt weniger(nur "pinpad.*" im Beispiel), aber zum Beispiel bei der Heizungssteuerung gibt es aktuell 3 Kategorien, "temperature.*", "windows.*" und "io_ports.*" (und es werden wohl noch mehr werden). JSON kann diese Hierarchie nativ darstellen, und das macht es IMHO einfacher, wenn ich mich auf eine Kategorie beschränken will mit meiner Applikation, da ich die Kategorie einfach so als Variable übernehmen kann, und nicht erst jeden Key parsen muss. Wegen MQTT mach ich gerne mal nen Vortrag, aber vorher möchte ich noch n bisschen damit rumspielen. Gibt auch einen ganz gutes Youtube-Video[1] dazu, ist allerdings ne gute Stunde lang. Aber Vortrag steht auf der ToDO-Liste :) --Tiefpunkt (Diskussion) 12:53, 18. Dez. 2012 (CET)