Poserspace: Unterschied zwischen den Versionen
Aus Stratum 0
(Start) |
(→Einsetzbare Geräte) |
||
| (9 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 19: | Zeile 19: | ||
Datenquellen -> Multiplexer -> Datensenken (Displays) | Datenquellen -> Multiplexer -> Datensenken (Displays) | ||
| + | |||
| + | Der Multiplexer sollte so flexibel wie moeglich sein: | ||
| + | *Logging supporten (ggf. auch per Post konfigurierbar) -DooM 12:25, 31. Okt. 2013 (CET) | ||
| + | *"Abonnements supporten" so dass einzelne Datenquellen selektiert werden koennen und ein Oputput nicht alle enthalten muss -DooM 12:25, 31. Okt. 2013 (CET) | ||
| + | ** Ich hatte mir als User-Interface eher den Multiplexer gedacht. Sprich: Will ich auf einem Display X Datenquelle Y anzeigen, sage ich das genau dort und das Routing wird entsprechend veranlasst. [[Benutzer:Drahflow|Drahflow]] ([[Benutzer Diskussion:Drahflow|Diskussion]]) 11:02, 2. Nov. 2013 (CET) | ||
| + | *Aggregations Features bieten um Daten vor dem Anzeigen bereits Serverseitig aufbereiten zu koennen (Durchschnittswerte/Extrema/Mittelwerte/Integrale usw.) -DooM 12:23, 31. Okt. 2013 (CET) | ||
| + | ** Ja. Insbesondere hätte ich gerne Predictors, wie z.B. KALMAN-Filter (Junge), um dann Abweichungen detektieren zu können. [[Benutzer:Drahflow|Drahflow]] ([[Benutzer Diskussion:Drahflow|Diskussion]]) 11:02, 2. Nov. 2013 (CET) | ||
== Datenformat == | == Datenformat == | ||
| Zeile 40: | Zeile 47: | ||
</pre> | </pre> | ||
| + | Hmm waere so etwas wie YAML nicht deutlich angenehmer als Tabellen? -DooM 12:25, 31. Okt. 2013 (CET) | ||
| + | |||
| + | <pre> | ||
| + | msgID: 1 | ||
| + | type: geo | ||
| + | streamID: $UUID | ||
| + | log: true | ||
| + | pos: | ||
| + | format:lat,lon | ||
| + | raw: 50,10 | ||
| + | username: Drahflow | ||
| + | time: 1383097977.120 | ||
| + | |||
| + | msgID: $UUID | ||
| + | type: geo | ||
| + | pos: | ||
| + | lat: 50.2 | ||
| + | lon: 10.2 | ||
| + | dispFormat: lat, lon | ||
| + | username: Rohieb | ||
| + | time: 1383097977.125</pre> | ||
| + | |||
| + | * streamIDs lassen sich abonnieren und das LOG feature bedingt sie um sie zuordnen zu koennen. | ||
| + | * gelogte MSG haben immer eine msgID auch wenn der sender keine sendet und lassen sich damit immer wieder abrufen | ||
| + | * alle RAW daten muessen human readable sein wenn dispFormat nicht definiert ist | ||
| + | * es muss einen Prozess geben neue types zu definieren (gemeinsam/demokratisch) und ggf. auch automatisiert. | ||
=== x-poserspace/scalar === | === x-poserspace/scalar === | ||
| Zeile 61: | Zeile 94: | ||
whatever:string, whatever+1:base64 | whatever:string, whatever+1:base64 | ||
| + | |||
| + | == Einsetzbare Geräte == | ||
| + | * Jede Menge 1280x1024-LCDs stehen noch ungenutzt im Space | ||
| + | * https://github.com/Swordifish90/cool-old-term | ||
Aktuelle Version vom 21. August 2014, 21:53 Uhr
| Poserspace
| |
|---|---|
| Kontakt: | Drahflow (Diskussion) |
| Status: | angekündigt (Was heißt das?) |
Inhaltsverzeichnis
Ziel
Der Hackerspace sieht nicht aus, wie epische Hacker-Lairs aus Movies. Dieses Projekt will das ändern.
Architektur
Datenquellen -> Multiplexer -> Datensenken (Displays)
Der Multiplexer sollte so flexibel wie moeglich sein:
- Logging supporten (ggf. auch per Post konfigurierbar) -DooM 12:25, 31. Okt. 2013 (CET)
- "Abonnements supporten" so dass einzelne Datenquellen selektiert werden koennen und ein Oputput nicht alle enthalten muss -DooM 12:25, 31. Okt. 2013 (CET)
- Ich hatte mir als User-Interface eher den Multiplexer gedacht. Sprich: Will ich auf einem Display X Datenquelle Y anzeigen, sage ich das genau dort und das Routing wird entsprechend veranlasst. Drahflow (Diskussion) 11:02, 2. Nov. 2013 (CET)
- Aggregations Features bieten um Daten vor dem Anzeigen bereits Serverseitig aufbereiten zu koennen (Durchschnittswerte/Extrema/Mittelwerte/Integrale usw.) -DooM 12:23, 31. Okt. 2013 (CET)
- Ja. Insbesondere hätte ich gerne Predictors, wie z.B. KALMAN-Filter (Junge), um dann Abweichungen detektieren zu können. Drahflow (Diskussion) 11:02, 2. Nov. 2013 (CET)
Datenformat
POST /display HTTP/1.0 Content-type: x-poserspace/geo X-column-1-name: lat X-column-1-type: number X-column-2-name: lon X-column-2-type: number X-column-3-name: username X-column-3-type: string X-column-4-name: time X-column-4-type: time X-time-column: 4 50 10 Drahflow 1383097977.120 50.2 10.2 Rohieb 1383097977.125 ...
Hmm waere so etwas wie YAML nicht deutlich angenehmer als Tabellen? -DooM 12:25, 31. Okt. 2013 (CET)
msgID: 1
type: geo
streamID: $UUID
log: true
pos:
format:lat,lon
raw: 50,10
username: Drahflow
time: 1383097977.120
msgID: $UUID
type: geo
pos:
lat: 50.2
lon: 10.2
dispFormat: lat, lon
username: Rohieb
time: 1383097977.125
- streamIDs lassen sich abonnieren und das LOG feature bedingt sie um sie zuordnen zu koennen.
- gelogte MSG haben immer eine msgID auch wenn der sender keine sendet und lassen sich damit immer wieder abrufen
- alle RAW daten muessen human readable sein wenn dispFormat nicht definiert ist
- es muss einen Prozess geben neue types zu definieren (gemeinsam/demokratisch) und ggf. auch automatisiert.
x-poserspace/scalar
X-column-*-label: Temperature
whatever:number
x-poserspace/xy
X-column-1-y: 2
whatever:number, whatever+1:number
x-poserspace/geo
X-lat-column: 0 X-lon-column: 1
lat:number, lon:number
x-poserspace/text
X-column-*-label: Label
whatever:string, whatever+1:base64
Einsetzbare Geräte
- Jede Menge 1280x1024-LCDs stehen noch ungenutzt im Space
- https://github.com/Swordifish90/cool-old-term
