[patch] 31_iLedBlub.pm: neues Modul für Xavax/Hama/BEKEN Bluetooth-RGB-LEDs E27

Begonnen von andim, 26 Januar 2018, 00:00:50

Vorheriges Thema - Nächstes Thema

andim

Hallo,

diese Lampen gibt es momentan noch bei pollin.de verfügbar, relativ günstig (~ 5 Teuronen):
https://www.pollin.de/p/led-lampe-xavax-e27-eek-a-7-w-530-lm-2700-k-rgb-bluetooth-534983
https://www.pollin.de/p/led-lampe-xavax-e27-eek-a-8-w-810-lm-2700-k-bluetooth-534984

Angehängt ist ein Patch (via git format-patch), der folgendes enthält:
- 31_iLedBlub.pm: neues Modul
- lib/Bluetooth/GATT.pm: erste Version eines endlich mal zentralisierten Bluetooth-GATT-Support-Interfaces (leeeeider nur Verwendung von gatttool command line, also keine schöne / schnellere Library in dieser Implementierung - aber das könnte man ja evt. ändern)
- verschiedene FIXMEs, die auf nervige Duplikation (Bluetooth) hinweisen
  (da ich jene Hardware nicht habe, kann ich keinen aktiven/risikolosen Umbau betreiben, daher nur Annotation)
- Einbindung in FHEM-Infrastruktur, wie von FHEM (How_to_write_a_patch etc.) gefordert

Das State-Handling im Modul ist bereits halbwegs ausgefeilt: es merkt sich relevante Settings korrekt, hat ziemlich dynamische/flexible Konfiguration, und es ist außerdem sichergestellt, dass bei toggle main-switch der vorherige Lampen-Zustand exakt wieder hergestellt ist.

Bin mit dieser initialen Version schon ziemlich glücklich  :-*
(allerdings war der Implementierungsaufwand auch nicht ganz unbeträchtlich - mehrere Abende)

Anlegen via
define NAME iLedBlub BTMAC
(BTMAC via Linux hcitool lescan)

Durch das Anlegen eines Dummy-Devices sollte sich die Funktionalität hoffentlich auch ohne Hardware besichtigen lassen.

Aufgrund der bei BLE-Devices üblichen hohen (Energy-Saving-)Latenz dauert eine erste Konfigurationsänderung der Lampe ca. eine halbe Sekunde, danach ca. 0,05s.

Referenz: https://wiki.fhem.de/wiki/BEKEN_iLedBlub

CoolTux

Ich glaube Du hast da etwas missverstanden. Du hast anscheinend ein komplettes eigenständiges Modul selber geschrieben. Dafür macht man kein Patch sondern stellt das Modul ein.
Ein Patch schreibt man nur wenn man Änderungen an einem fremden Modul vor nimmst und möchte das diese Änderungen vom Moduleigentümer eingepflegt wird.

Mach mal den Patch hier als Anhang weg und stelle bitte die Moduldatei ein. So kann man das ja nicht vernünftig lesen.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

andim

"Missverstanden"?

Hier kommt eher der Eindruck rüber, FHEM hat da was mistverstanden...  ;)

Das ist die stark übliche Arbeitsweise in sehr vielen Umgebungen (z.B. bei Einsatz von git, svn etc.) - man zieht alles mit rein, was für diese change state transition "nötig"/"erweitert sinnvoll" ist, und stellt das dann bereit (als irgendein auf standardisiertem universal diff aufbauendes Format, welches somit "überall" verwendet werden kann [abseits von elitären sehr fragwürdig agierenden Proprietär-Anbietern, die das sichergestellt nicht-funktionierend genau 5% abweichend anbieten]).

Wenn überhaupt (wenn das aus relevantem Grund nicht so gemacht werden sollte), dann ist die Beschreibung im Wiki (https://wiki.fhem.de/wiki/How_to_write_a_patch) nicht korrekt - wenn eine Arbeit über einen "erweiternden Patch-Hotfix" (deutsch: "Flicken-Aktivität", also eine Verbiegung existierender Bestandteile) hinausgeht, dann sollte da eine Anmerkung mit drinstehen, dass das dann genau anders zu behandeln ist.
Bei https://wiki.fhem.de/wiki/DevelopmentModuleIntro (wo das themenmäßig erwähnt sein müsste, da es auf How_to_write_a_patch nicht steht) steht AFAICS auch nix.
(falls gewünscht könnte ich dort entsprechend erklärte Korrekturen vornehmen)

Ich frage mich dennoch, wie ich bei "Anlegen eines Moduls mit einem Support-Modul und mehreren Anmerkungen in anderen Modulen" das dann sinnvoll "anders" erreichen soll.

Man kann argumentieren, dass die FIXME-Annotationen in den anderen Modulen stark dazugehören (das gilt natürlich noch mehr für die Änderungen in CHANGED , HISTORY , MAINTAINER.txt, wie von MAINTAINER.txt gefordert - diese sind eigentlich direkt darauf bezogen, und werden oftmals auch direkt mit einem neuen Modul abgeändert).

Andererseits könnte man hinsichtlich der Duplikations-FIXME-Annotationen argumentieren, dass diese ja "generell" (also: bereits früher!) gelten, also losgelöst vom neuen Bluetooth-Modul relevant sind, somit evt. in einem separaten Patch.

Nun gut, hier kommen auf jeden Fall mal die beiden Module

31_iLedBlub.pm
lib/Bluetooth/GATT.pm


Grüße!

barneybaer


andim

Ohje, jetzt muss ich zu Kreuze kriechen und Abbitte leisten:
die initiale Version funktioniert NICHT.

Ich habe relativ spät die Bluetooth-Funktionalität nach GATT.pm ausgelagert, und dummerweise hat die Plattform die nervige Verhaltensweise, dass zwar manches reloaded wird, nicht aber die Location/Definition von Funktionen. Da ich keinen harten Reset (shutdown restart) von FHEM gemacht hatte, war also an der falschen Stelle noch eine "funktionsfähige" Variante der Funktionen verfügbar, somit habe ich nicht gemerkt, dass es Namespacing-Probleme gab.

Nun gut, hier nun jedenfalls eine neue Version, mit folgenden Features:
- Namespacing-Probleme behoben
- initial startup readings state nun korrekt (Readings sind nicht direkt in _Define korrekt verfügbar, sondern erst später, da FHEM erst später ($init_done) volllständig initialisiert ist)
- BlockingKill experimentell deaktiviert (multiple command submission cancelt sich sonst gegenseitig aus, ist also wohl noch schlechter); vielleicht gibt es ja in Zukunft neuen Bluetooth-Support, dann dürfte das alles angenehmer werden...
- kaputtes SetExtensions gefixt (multi-arg wie z.B. bei "blink" ging nicht - PLAYBULB hat noch das gleiche Problem)
- Problem bei initial state update gefixt
- minor stuff

barneybaer

So hab das ganze mal mit meinen neuen 00111974 durch getestet und alles was geht ist Licht aus :) kann ich sonst wie behilflich rein?

andim

Der Alltag wäre ja wirklich langweilig, wenn...  :-[

Super, Default-Apply erwischt, und unvollständigen Kommentar generiert.


Hier müsste man jetzt eventuell mal sehen, ob alle Readings angelegt wurden. Wäre gut denkbar, dass es Probleme gibt, wenn die nicht verfügbar sind (die erste Aktion in FHEMWEB führt dann nämlich genau dazu, dass es stockdunkel wird...).

Für die 00111974 hab ich hier:
allowColor, allowLight, light, modifiedComponent, onoff, rgb, state, stateLight.
(z.B. also auch kein stateColor, da das bei dem Modell nicht aktiv verwaltet wird)

Man sollte dann wohl in Richtung Logging gehen (FHEMWEB Raum/Kategorie FHEM, dort Global, dort dann verbose auf >= 4 setzen). Danach dann Logfile durchschauen. Ich habe hier relativ klar die state
transitions diverser Variablen mitgelogged. Wenn man sich mit der Ausgabe beschäftigt (und mit den Folgen von User-Aktionen in FHEMWEB auf die dortigen relevanten Readings / state vars), dann könnte bald klar werden, wo es momentan klemmt. Man muss allerdings anmerken, dass das state handling/Verhalten relativ ausgefeilt/trickreich ist (..."hätte sein sollen"?), um "genau das richtige Verhalten in allen Momenten" hinzubekommen.

Hier wieder mal neue Versionen:
- 31_iLedBlub.pm hätte am Anfang Readings force-anlegen sollen, sonst ist diese Storage nicht vorhanden, und dann gibt es Probleme
- GATT.pm hat eine kleinere Fehler-Handling-Verbesserung

Das ganze Thema ist doch etwas hartnäckiger als gedacht  :(

barneybaer

So neue Version probiert. Könnte die Bad Lampe 3x an und ausschalten und dann wars das schon, müsste die Lampe erst per Hand aus/einschalten damit fhem. Sie wieder steuern kann. Hier nen log mit verbose 4.
23:08:38 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:38 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:38 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:40 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:40 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:43 3: iLedBlub_Define (Bad_Lampe) - initial state: onoff 1 valAllowLight  light 0 valAllowColor 1 rgb ff0000
2018.01.31 23:08:43 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:43 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:43 3: iLedBlub_Define (Kueche_Lampe) - initial state: onoff 1 valAllowLight  light 0 valAllowColor 1 rgb ff0000
2018.01.31 23:08:43 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:43 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:43 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:43 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:44 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:44 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:56 4: (Sub iLedBlub_Set - Bad_Lampe) cmd off @aa
2018.01.31 23:08:56 4: (Sub iLedBlub_Run - Bad_Lampe) - cmd onoff arg 0
2018.01.31 23:08:56 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:56 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:56 4: (Sub iLedBlub - Bad_Lampe) - pre  alt_power 0 r_valStateLight  r_valStateColor 1 modifiedComponent 1 r_valOnOff 0
2018.01.31 23:08:56 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:56 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:56 4: (Sub iLedBlub - Bad_Lampe) - post alt_power   r_valStateLight 0 r_valStateColor 0
2018.01.31 23:08:56 4: (Sub iLedBlub - Bad_Lampe) - r_valStateLight 0 light 0 r_valStateColor 0 rgb ff0000
2018.01.31 23:08:56 4: (Sub iLedBlub - Bad_Lampe) - Call BlockingRun
2018.01.31 23:08:56 4: (Sub iLedBlub_Run - Bad_Lampe) - Running nonBlocking
2018.01.31 23:08:56 4: gattWaitIdle wait
2018.01.31 23:08:56 4: gattWaitIdle ok
2018.01.31 23:08:56 4: bluetooth_gatt_cmd_execute gatttool -b 00:F2:A3:D3:02:C4 --char-write-req -a 0x0028 -n 00



018.01.31 23:23:42 4: bluetooth_gatt_cmd_execute result Characteristic value was written successfully 2018.01.31 23:23:42 4: gattWaitIdle wait
2018.01.31 23:23:42 4: gattWaitIdle ok
2018.01.31 23:23:42 4: bluetooth_gatt_cmd_execute gatttool -b 00:F2:A3:D3:02:C4 --char-read -a 0x0025
2018.01.31 23:23:42 4: bluetooth_gatt_cmd_execute result Characteristic value/descriptor: 01 00 00 00 01 00 01 ff 01 ff
2018.01.31 23:23:42 4: res Characteristic value/descriptor: 01 00 00 00 01 00 01 ff 01 ff parts Characteristic value/descriptor 01 00 00 00 01 00 01 ff 01 ff values 1 0 0 0 1 0 1 255 1 255
2018.01.31 23
:23:42 4: LedBlub_Run r_valStateLight 0 r_val_l 255 r_valStateColor 0 r_rgb FF0000 r_val_r 255 2018.01.31 23:23:42 4: EncodeLEDConfig 0000
2018.01.31 23:23:42 4: EncodeLEDConfig 0000
2018.01.31 23:23:42 4: EncodeLEDConfig 0000
2018.01.31 23:23:42 4: EncodeLEDConfig 00ff
2018.01.31 23:23:42 4: EncodeLEDConfig 00ff
2018.01.31 23:23:42 3: EncodeConfigWord l 255 ena l 0 UNK 0 ena UNK 0 rgb 255 0 0 ena r/g/b 0 0 0: 00000000000000ff00ff
2018.01.31 23:23:42 4: gattWaitIdle wait
2018.01.31 23:23:42 4: gattWaitIdle ok
2018.01.31 23:23:42 4: bluetooth_gatt_cmd_execute gatttool -b 00:F2:A3:D3:02:C4 --char-write-req -a 0x002a -n 00000000000000ff00ff
2018.01.31 23:23:43 4: bluetooth_gatt_cmd_execute result Characteristic value was written successfully 2018.01.31 23:23:43 4: gattWaitIdle wait
2018.01.31 23:23:43 4: gattWaitIdle ok
2018.01.31 23:23:43 4: bluetooth_gatt_cmd_execute gatttool -b 00:F2:A3:D3:02:C4 --char-write-req -a 0x0028 -n 00
2018.01.31 23:23:43 4: bluetooth_gatt_cmd_execute result Characteristic value was written successfully
2018.01.31 23:23:43 4: gattWaitIdle wait
2018.01.31 23:23:43 4: gattWaitIdle ok
2018.01.31 23:23:43 4: bluetooth_gatt_cmd_execute gatttool -b 00:F2:A3:D3:02:C4 --char-read -a 0x0025
2018.01.31 23:23:43 4: bluetooth_gatt_cmd_execute result Characteristic value/descriptor: 00 00 00 00 00 00 00 ff 00 ff
2018.01.31 23:23:43 4: res Characteristic value/descriptor: 00 00 00 00 00 00 00 ff 00 ff parts Characteristic value/descriptor 00 00 00 00 00 00 00 ff 00 ff values 0 0 0 0 0 0 0 255 0 255
2018.01.31 23:23:43 4: iLedBlub_ComponentsStateDetermine Bad_Lampe 1 0 255 0 255 0 0 0 0 2018.01.31 23:23:43 4: (Sub iLedBlub_Run - Bad_Lampe) - Return to consuming app starting
2018.01.31 23:23:43 4: (Sub iLedBlub_Run - Bad_Lampe) - c_light 100 c_rgb FF0000
2018.01.31 23:23:43 3: valStateDevice 0 valStateLight 0 valStateColor 0
2018.01.31 23:23:43 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:23:43 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:23:43 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:23:43 4: (Sub iLedBlub_BlockingDone - Bad_Lampe) - Finished


Und das ist bei mir anders:
my $iLedBlub_00111974_1_mac_vendor = "00:F2:A3"; - - für meine Modellbezeichnung
Müsste man noch irgendwie anders das Modell bestimmen können.

barneybaer


andim

Zitat von: barneybaer am 31 Januar 2018, 23:15:58
So neue Version probiert. Könnte die Bad Lampe 3x an und ausschalten und dann wars das schon, müsste die Lampe erst per Hand aus/einschalten damit fhem. Sie wieder steuern kann. Hier nen log mit verbose 4.
23:08:38 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:38 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:38 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:40 4: (Sub iLedBlub_Set - Bad_Lampe) cmd ? @aa
2018.01.31 23:08:40 3: model: iLedBlub_00111974 feat_rgb: 0
2018.01.31 23:08:43 3: iLedBlub_Define (Bad_Lampe) - initial state: onoff 1 valAllowLight  light 0 valAllowColor 1 rgb ff0000


Verflixt, warum ist hier valAllowLight leer??
Laut iLedBlub_firstRun() müsste es auf einen gültigen Wert (forciert) gesetzt worden sein.

Zitat von: barneybaer am 31 Januar 2018, 23:15:58
2018.01.31 23:08:56 4: (Sub iLedBlub - Bad_Lampe) - pre  alt_power 0 r_valStateLight  r_valStateColor 1 modifiedComponent 1 r_valOnOff 0
[/code]

Dito hier r_valStateLight. Aber das dürfte mit dem anderen zusammenhängen.


Zitat von: barneybaer am 31 Januar 2018, 23:15:58
Und das ist bei mir anders:
my $iLedBlub_00111974_1_mac_vendor = "00:F2:A3"; - - für meine Modellbezeichnung
Müsste man noch irgendwie anders das Modell bestimmen können.


Alptraum. Wir haben die erste Lieferung jenseits meiner Gerätschaften, und schon ist die Kategorisierung wieder zum Teufel  :'(
Wenn sich die momentan "versuchte" Farb-/Weiss-Unterscheidung per MAC halten lassen sollte, dann müsste man auf jeden Fall ein Array von Kandidaten-MACs maintainen.


Darauf folgendes Posting:
Zitat von: barneybaer am 31 Januar 2018, 23:33:12
Jetzt scheint es auch dauerhaft zu funktionieren.

Dann hat sich wohl irgendein Reading nun "verfestigt", was es am Anfang wohl nicht war.

Ich sollte wohl bei mir mal einen erweiterten Reset machen und dann das Verhalten einer 00111974 noch einmal beobachten.

barneybaer

Also ich bin bis jetzt zufrieden, sicherlich geht das ganze auch ohne es in ne GATT.pm auszulagern,aber Alexa hat 2 Räume mehr zum schalten, wenn das Kind wieder das Licht an lässt ;D

andim

Zitat von: barneybaer am 01 Februar 2018, 18:45:22
Also ich bin bis jetzt zufrieden, sicherlich geht das ganze auch ohne es in ne GATT.pm auszulagern,aber Alexa hat 2 Räume mehr zum schalten, wenn das Kind wieder das Licht an lässt ;D

Positive Aussage, danke!  :)


""Nein geht es nicht.""  ;)
Ich hatte wirklich keine Lust, die dritte (vierte? fünfte?) quadruplizierte (und dann auch noch intern recht krass aufgeblähte) Bluetooth-Zugriffs-Geschichte sehen zu müssen (ich habe in meinem mittel-langen Leben schon wirklich mehr als genug nervige Folge-Schäden gesehen - auch heute...). Daher habe ich das von mir benutzte Interface als ersten Schritt wenigstens mal zentralisiert/öffentlich gehalten. Ob das was nützt, wenn in hoffentlich näherer Zukunft vielleicht stattdessen ein echtes asynchron arbeitendes Bluetooth-Interface verfügbar sein sollte, weiß ich natürlich nicht (es sei denn, man würde dann 3 Consumer dieses schlechteren Interfaces effizient/robust jeweils gleichartig modernisieren können!), aber zumindest ist diese Funktionalität mal nicht privat gehalten.

[zu Alexa/Siri werden mich keine zehn Pferde ziehen - eine Anwendungs-Alternative ist angeblich Mycroft]

Und den Licht-an-Tür-auf-Bug hat leider wohl fast jedes Kind, könnte man vermuten  :'(