deCONZ Window covering device: bri vs. lift

Begonnen von Weisswurstverkäufer, 19 Juli 2023, 08:48:17

Vorheriges Thema - Nächstes Thema

StephanFHEM

Dann hatte ich noch eine etwas ältere Version. Bei mir war es noch die fyrtur_block-out_roller_blind.json

Jamo

Hi, die aktuelle GW Version ist 2.27.6, mit der fw Version 0x26530900 (Conbee III)
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

Strictor

Hallo zusammen,

ich habe eine frische deconz VM aufgesetzt mit der neusten Gateway Version 2.27.6, mein Fyrtur Rollo wird auch erkannt und kann über die Phoscon App gesteurt werden, aber über FHEM nicht.
Was muss nun, wenn man keine alte blind.json als Sicherung hat, in eine neue geschrieben werden um das Rollo wieder per FHEM ansteuern zu können?

Jamo

Hallo Strictor,
Was muss nun, wenn man keine alte blind.json als Sicherung hat, in eine neue geschrieben werden um das Rollo wieder per FHEM ansteuern zu können?das ist hier im Thread ab #6 beschrieben.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

JF Mennedy

Moin zusammen,

in meiner letzten 31_HUEDevice.pm war noch ein Fehler, weshalb der Befehl "pct" nicht mehr funktionierte.

Das ist in dieser Version korrigiert. Die Version basiert auf die letzte veröffentlichte 31_HUEDevice.pm

An wen muss man sich wenden, wenn das in die offizielle Version übernommen werden soll..??

Gruss Jan

justme1968

vielen dank für den vorschlag wie lift ins modul übernommen werden kann.

ich würde das aber lieber ein wenig anders umsetzen:
- ohne eigenen subtype -> subtype soll nur zwischen generellen geräte arten unterscheiden.
  nicht zwischen gleichen geräten (hier rollläden) unterscheiden die sich nur in details
  unterscheiden.
- denn abhängig vom subtype eigene readings und kommandos umzusetzen bedeutet das sich
  unterschiedliche angebundene blinds nicht mehr gemeinsam über fhem regex steuern lassen
- es muss an vielen stellen auf diesen unterschied eingegangen werden. z.b. ist der code für
  icons nicht mehr für alle geräte gleich.
- die sprachsteuerung wird aus den gleichen gründen ebenfalls sehr problematisch

mein vorschlag wäre:
- lift als reading bereitzustellen wenn es vom api kommt
- pct automatisch aus lift oder bri abzuleiten
  nur an einer stelle an der die werte rein kommen
- pct = 0 bedeutet zu, pct = 100 bedeutet offen.
  wie bisher und wie bei allen anderen devices auch
- wenn es ein reading lift gibt wird es auch als kommando bereitgestelt
- die bisherigen kommandos bleiben aber auch dann bestehen und verhalten sich wie bisher
- icon erzeugung bleibt gleich

gibt es einwände?


ps: ganz unabhängig davon finde ich die phoscon änderungen etwas unglücklich. neben der immer größeren abweichung vom hue api ist die benennung 'lift' mit der bedeutung 0 = offen und 100 = zu nicht gerade intuitiv. lift bedeutet für mich in der übersetzung etwa anheben. anheben 0
  ist aber nicht ganz oben sondern ganz unten.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

JF Mennedy

Hallo,

danke für die Rückmeldung..

Dein Vorschlag ist wahrscheinlich die bessere Variante.. Ich hatte mir halt damit beholfen, ein SubDevice anzulegen, um die anderen Geräte bzw. den Code nicht zu verwursteln...

Da lift in phoscon jedoch mit 0 = auf und 100 = zu beschrieben wird und auch so im ASC-Modul verarbeitet wird, ausser man setzt es auf attr ASC 2, was auch in der Doku als Homematic Style betitelt wird, würde ich eher sagen pct 0 = auf und pct 100 = zu.

Meine Rolläden, die über Encocean eingebunden sind, arbeiten auch so...

Gruss Jan

justme1968

enocean ist glaube ich das einzige andere system das 0=auf/hell und 100=unten/dunkel verwendet.

homematik, zigbee, alle möglichen lampen und auch siri und alexa verwenden 0=dunkel und 100=hell. auch die gruppenberechnung für pct/helligkeit funktioniert nur wenn alle beteiligten geräte das gleiche schema verwenden.

deshalb der vorschlag lift belassen wie es ist (0=hell) und pct sie zu handhaben wie bisher und (fast) überall sonst (100=hell)

ich stelle die version zum testen dann hier ein.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

JF Mennedy

OK... Ich verwende sowieso nur lift für die Steuerung der Rollos...

Danke und Gruss Jan