Aufgrund der aktuellen Ereignisse mit dem Harmony Hub Modul würde ich mir eine Kennzeichnung für jedes Modul wünschen ob dieses auf einer offiziellen API aufbaut und ob diese API lokal ist.
Gibt es hierzu bereits Überlegungen?
die idee finde ich gut.
das könnte man über zwei item einträge im im pod teil der doku lösen und dann z.b. per icon in der commandref darstellen.
Das LuftdatenInfo Modul bieten beide Möglichkeiten, entweder Daten vom Server holen oder über das lokale Netzwerk.
Dieses Verhalten sollte dann auch abbildbar sein. Ggf. als optional markieren.
anbei ein vorschlag wie man das umsetzen könnte.
im pod teil können ein oder mehrere flags gesetzt werden:
=item cloudfree
=item openapi
in der commandref wird dann für jedes gesetzte flag ein icon angezeigt.
was noch fehlt sind schöne und kleine icons :), die anzeige auf der device seite wenn man auf help klickt und es wäre in der modularen commandref schön wenn man die icons direkt in der summary zeile sieht.
Muss ich dann auch irgendwann auch noch anfangen, im help-Modul img Tags rauszuschmeissen, damit die Anzeige auch in telnet funktioniert?
Kennzeichnen finde ich gut - aber bitte nicht grafisch.
und das cloud-free symbol finde ich jetzt auch eher ungünstig. Die Aussage "cloud-free" ist positiv aber das icon heult aber gleich.
Finde die Idee auch gut. Grafik kann, muss aber nicht
Zitat von: justme1968 am 21 Dezember 2018, 09:29:24
im pod teil können ein oder mehrere flags gesetzt werden:
=item cloudfree
=item openapi
excellent, when shall we start?
statt des icons könnte man auch einfach den text einblenden und für fhemweb per css auf ein icon abbilden.
Die Resonanz war jetzt nicht üppig, aber positiv.
Wie geht es weiter?
Warten wir darauf, dass ein Entscheidungsträger diesen Thread liest und das zu einer Vorgabe für die Modulautoren macht?
Nur für den Fall, dass das so kommt:
Unter Cloudfree kann ich mir was vorstellen, aber wo stehen die Definitionen, wie das mit der API zu verstehen ist? Und welche Varianten gäbe es da noch? Z.B.: was wäre CUL_HM: das eigentliche Protokoll ist reverse-Engineered, also eigentlich "unfree". Vermutlich ist es mit vielen Signalduino&Co-Protokollen ähnlich.
Für MySensors (also 00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm) wäre das so passend?
Zitat=item cloudfree
=item openapi
(Dann bastle ich das bei Gelegenheit einfach präventiv rein, oder stört das irgendwie)?
Zitat von: willib am 05 März 2019, 13:20:26
Die Resonanz war jetzt nicht üppig, aber positiv.
Damit es etwas "üppiger" wird: Ich bin von der Idee sehr angetan!
Habe gerade erst angefangen mich mit ZigBee (per Philips Hue Bridge) zu beschäftigen. Da ist es schon sehr von Vorteil, wenn man weiß, ob die Hue Bridge zum "normalen" Betrieb mit FHEM Hue-Devices:
- ständig Internetverbindung benötigt
- nur für ggf. zu tätigende Firmware-Updates oder die Ersteinrichtung von (weiteren) Komponenten Zugriff auf die Philips Server benötigt
- der Internetzugang prinzipiell über den Router gesperrt werden kann
Danke für's Einbringen dieser Möglichkeit!
Finde ich eigentlich gut. Aber:
Könntet ihr bitte eine genaue Abgrenzung erstellen, wann etwas als cloudfree / openapi markiert werden kann?
gefällt dem onkel.
und weil ja schon hue erwähnt wurde ... sollte man nicht auch noch eine info für "reverse engineered" beilegen?
dann weiß ma wenigstens, dass es zu ausfällen kommen kann, wenn der hersteller wieder mal wichtig sein will.
Zitat von: the ratman am 05 März 2019, 15:17:54
sollte man nicht auch noch eine info für "reverse engineered" beilegen?
dann weiß ma wenigstens, dass es zu ausfällen kommen kann, wenn der hersteller wieder mal wichtig sein will.
Erfahrungsgemäß wird anders rum ein Schuh draus:
was reverse engineered ist, ohne dass der Hersteller noch direkten Zugriff für updates hat, (weil er ausgesperrt wurde!) funktioniert zuverlässig ;D .
ein flag für internetnutzung finde ich auch gut.
den nutzen des apiflag verstehe ich allerdings nicht.
wenn ich den thread vom harmony hub richtig verstanden habe, wurde eine "inoffizielle api" genutzt, die dann von logitech gestrichen wurde.
offizielle api haben aber nicht automatisch eine unbegrenzte garantie auf verfügbarkeit. siehe fritzbox oder yahoo wetter.
Naja ..die API ist offiziell,nur das Produkt verwendet es nicht mehr ...
Kann jeder Hersteller bei einem Update machen (leider)
Inzwischen könnte man das auch direkt als Keyword in die Metadaten packen (siehe Meta.pm (https://forum.fhem.de/index.php/topic,97589.0.html)).
Diese Daten werden auch über den Installer (https://forum.fhem.de/index.php/topic,98381.0.html) grafisch dargestellt (in Textform) und sind außerdem über diesen auch durchsuchbar (man sieht, welche Module alle zu welchem Keyword zugeordnet sind).