Module Kennzeichnen mit Cloudfree und offizielle API

Begonnen von willib, 19 Dezember 2018, 15:44:34

Vorheriges Thema - Nächstes Thema

willib

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?
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

igami

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.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj

und das cloud-free symbol finde ich jetzt auch eher ungünstig. Die Aussage "cloud-free" ist positiv aber das icon heult aber gleich.

Amenophis86

Finde die Idee auch gut. Grafik kann, muss aber nicht
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

immi

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?

justme1968

statt des icons könnte man auch einfach den text einblenden und für fhemweb per css auf ein icon abbilden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

willib

#9
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?
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Beta-User

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)?


Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

r00t2

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!
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Christoph Morrison

Finde ich eigentlich gut. Aber:
Könntet ihr bitte eine genaue Abgrenzung erstellen, wann etwas als cloudfree / openapi markiert werden kann?

the ratman

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.
→do↑p!dnʇs↓shit←

Beta-User

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 .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files