Homebrew Devices HBW-LC-BL-3-In6

Begonnen von Funsailor, 27 Oktober 2020, 21:45:52

Vorheriges Thema - Nächstes Thema

Funsailor

Ich habe schon vor etwa 25 Jahren meine Rollladen im EG elektrisiert. Am Anfang wurde alles von Hand bedient, vor einigen Jahren habe ich dann die einzelnen Fenster mit einigen HM-LC-BL1PBU-FM und FHEM automatisiert.

Im Ess- und Wohnzimmer habe ich jeweils in einem Rollladenkasten eine "Zentrale" (einfache Relais um die Motoren anzusteuern) für drei Motoren die mittels Niederspannungsschaltern angesteuert werden.  Mit drei einfachen Kippschaltern
(z.B.: https://www.conrad.de/de/p/eledis-1a24-nf1stse-kippschalter-250-v-ac-2-a-2-x-ein-aus-ein-tastend-0-tastend-1-st-705100.html?hk=SEM&WT.srch=1&WT.mc_id=google_pla&s_kwcid=AL%21222%213%21444073569960%21%21%21g%21%21&ef_id=EAIaIQobChMI3KzK_63V7AIVQ-N3Ch3PWgKKEAQYGyABEgLoP_D_BwE%3AG%3As&gclid=EAIaIQobChMI3KzK_63V7AIVQ-N3Ch3PWgKKEAQYGyABEgLoP_D_BwE)
kann ich mit einem Griff je eine Fensterfront (händisch) bedienen. Die drei Schalter sind an einem Alublech befestigt, das Blech ist in den Ausschnitt des Gurtwicklers eingeklebt. In diesen Gurtkasten liegen auch die Kabel für die Versorgungsspannung der Relaisschaltungen.
Die erste Idee, die "Zentrale" mit drei HMW-LC-Bl1-DR zu ersetzen, scheitert am Platz. Das wird mir dann zu eng im Rollladenkasten, wenn der Rollladen mal extrem schief aufgewickelt wird, können die Module beschädigt oder abgerissen werden.

Um das ganze trotzdem Smart zu machen, habe ich nun die Software für ein HBW-LC-BL-3-In6 Device geschrieben (bzw. aus anderen Devices zusammen kopiert).

Sieht soweit gut aus, alle Eingänge werden eingelesen, die Ausgänge (bisher LEDs) werden richtig angesteuert. Ich kann auch z.B.: die Eingänge eines HMW-LC-Bl1-DR peeren um einen der Blind-Channels  anzusteuern und umgekehrt mit den Eingängen des HBW-LC-BL-3-In6 den Blind- Channel des HMW-LC-Bl1-DR  bedienen.

Was leider nicht geht, ist das peeren mit sich selbst... da tut sich nichts. Ich dachte, das Thema wäre inzwischen gelöst, finde aber nicht den richtigen Ansatz.

Kann mir da jemand auf die Sprünge helfen?

Wie ich eben gesehen habe, wird ein seltsamer Channel  angelegt (im Bild 185) wenn ich den Eingang peere...
Ich habe das gesamte EEProm gelöscht....  mit 0 ...  8)
Um eine vernünftige Adresse zu bekommen, habe ich bei mir in HBWired.cpp folgende Änderung gemacht:

void HBWDevice::readAddressFromEEPROM(){
   uint32_t address = 0;
   
   for(byte i = 0; i < 4; i++){
      address <<= 8;
      address |= EEPROM.read(E2END - 3 + i);
   }
   if(address == 0xFFFFFFFF)
      address = 0x42FFFFFF;
   if(address == 0x0000000)
      address = 0x42FFFFFF;   
   setOwnAddress(address);
}


Ich wollte sichergehen, das nach "ClearEE" auch wirklich nichts mehr im EEProm steht.
Trotzdem bekomme ich diese seltsame Channels.
Ich denke, da stimmt etwas im Code nicht.
Habe aber keine Ahnung wo es klemmt... ich habe nur 10 Channels angelegt  ::).
Ich könnte mir vorstellen, das die Zeile:

#define LINKADDRESSSTART 0x48   // address step 9

falsch ist.  Aber was muss da rein und wie berechne ich das richtig?
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -

loetmeister

Hi,

ich versuch mich mal mit ein paar Lösungsideen... :)

ZitatIch habe das gesamte EEProm gelöscht....  mit 0 ...  8)
Eine "leeres" EEPROM sollte 0xFF also 255 haben. Nicht "0". Es gibt ein Bespiel Arduino Sketch, da 0 auf 0xFF ändern. Oder mit dem Config Taster löschen...

ZitatTrotzdem bekomme ich diese seltsame Channels.
Du meinst die Peerings mit den unbekannten Kanälen? Das liest FHEM nur anhand der XML aus, der Code im Device ist erst mal egal...  ;)

Peerings im Device selbst sollten möglich sein.
Bzgl. der Konfig...
address_start="0x48" in der XML muss mit #define LINKADDRESSSTART 0x48 im Sketch überein stimmen. Den Wert kannst du selber festlegen, darf sich aber natürlich nicht mit anderen Bereichen überschneiden. address_step muss zu dem Peering typ passen, in deinem Fall HBWLinkBlindSimple. "9" ist ok.
Ich nehme die nächste freie Adresse nach der Kanalkonfiguration (struct hbw_config) + etwas Puffer. (falls man noch Kanäle hinzufügt, und nicht den Speicherbereich der peerings löschen muss)

In deinem Sketch fehlt die Peering Konfig für die Taster (HBWLinkKey).
Das was in der XML steht würde ok sein, müsstest du dann aber auch im Sketch eintragen
<paramset id="hmw_input_ch_link" type="LINK" channel_param="CHANNEL" peer_param="ACTUATOR" count="20" address_start="0x13C" address_step="6">

Glaube auch die Kanalkonfiguration überscheidet sich...
<paramset id="hmw_blind_ch_master" type="MASTER" address_step="7" address_start="0x07">
...
<paramset id="hbw_input_ch_master" type="MASTER" address_start="0x19" address_step="2">

0x07 + 3 * 7= 0x1C als nächste freie Adresse.... nicht "0x19"
id="hmw_analog_ch_master" passt dann auch nicht.


Gute Quelle für die Grundlagen:
HomeBrewWired - Das Tutorial
https://forum.fhem.de/index.php/topic,61780.0.html


Gruß,
Thomas

Funsailor

Hallo Thomas,
vielen Dank für die schnelle Antwort.

Das in den Zellen von EEprom/FRAM/Flash etc. nach dem löschen 0xFF drin steht ist mir klar. Löschen belastet die Zelle, auf 0 setzen nicht.
Mit dem Wissen habe ich schon vor 30 Jahren einen Laufzeitzähler aufgebaut.
Ich wollte nur sichergehen das wirklich nichts mehr im EEProm steht.

Eigentlich hatte ich das mit den Adressen in der Config - Struktur und Zuordnungen im XML verstanden, aber im Kommentar der Struktur die Startadresse der keysCfg nicht geändert. Und dann diesen Wert genommen. Ärgerlich..... :-[ :-[
Mit dem Hinweis auf HBWLinkKey habe ich dann dieses Thema https://forum.fhem.de/index.php?topic=104354.40 gefunden. Dort wird das mit den Offsets sehr gut erklärt.
Außerdem fand ich dort die Lösung für das auslesen des STATE der Schalter (HBWSenSC). Ich habe das dann eingebaut, aber bekomme den Status nicht zurück.

Bei den Adressen bin ich mir eigentlich sicher, das Sie richtig sind. Die Peers funktionieren alle und es werden keine Phantom-Channels angelegt.
Was habe ich übersehen? ::)

Gruß
Michael
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -

loetmeister

Hi Michael,

das sieht ja doch sehr gut aus.  8)

Bekommst du den Status der "sensor" Kanäle, wenn du ein "get state" machst? Wenn ja, dann ist nur das NOTIFY im Kanal nicht aktiviert. Ich hatte das so eingestellt, das es standardmäßig aus ist um nicht den Bus zuzumüllen (grade wenn man die Eingänge mit Tastern o.ä. teilt)
Kannst du in der Kanalkonfiguration mal nachsehen?

HBWSenSC.h
struct hbw_config_senSC {
  uint8_t n_input_locked:1;   // +0.0    0=LOCKED, 1=UNLOCKED (default)
  uint8_t n_inverted:1;       // +0.1    0=inverted, 1=not inverted (default)
  uint8_t notify_disabled:1;  // +0.2    0=ENABLED, 1=DISABLED (default)


Gruß,
Thomas

Funsailor

Hi Thomas,
den "notify" habe ich in der Channel Configuration eingeschaltet.

Das ist auf dem Bus zu sehen:
1. Get State bei nicht betätigtem Schalter:

FD 42 00 00 18 1A 00 00 00 01 04 53 09 C0 3E
FD 00 00 00 01 38 42 00 00 18 05 69 09 00 AC 5E
FD 42 00 00 18 19 00 00 00 01 02 81 70

2. Get State bei betätigtem Schalter:

FD 42 00 00 18 1A 00 00 00 01 04 53 09 C0 3E
FD 00 00 00 01 38 42 00 00 18 05 69 09 C8 ED D6
FD 42 00 00 18 19 00 00 00 01 02 81 70


Soweit ich gelesen habe, ist 00 = Off und 0xC8 = 200 = On 
Soweit ist das richtig.

Die beiden folgenden Logauszüge sind für den zweiten Fall
Log bei Verbose 5:

2020.10.29 21:51:02 5: HBW_LC_Bl_3_HBW7296280: HM485_SendCommand: 5309
2020.10.29 21:51:02 4: hm485: hm485: TX: (119) I[1](0,F,B)(1A) 00000001 -> 42000018 [4] 53(S) 09
2020.10.29 21:51:02 5: HBW_LC_Bl_3_HBW7296280: HM485_DoSendCommand: hmwId = 42000018 data = 5309 requestId = 119
2020.10.29 21:51:02 5: HBW_LC_Bl_3_HBW7296280: HM485_ProcessChannelState: hmwId = 42000018 Channel = 10 msgData = 6909C8 actionType = response


Die Antwort
   
Zitat"Channel = 10 msgData = 6909C8"
also "i Channel 9 Value C8" sieht auch gut aus...

Vollständigkeitshalber noch das HMWLog mit Verbose 4:

2020.10.29 21:51:02.454 4: HM485d: Rx: FD0E7753C8420000181A000000015309
2020.10.29 21:51:02.457 5: SW: fd420000181a00000001045309c03e
2020.10.29 21:51:02.460 3: HM485d: Tx: (119:1) I[1](0,F,B)(1A) 00000001 -> 42000018 [4] 53(S) 09 {C03E}
2020.10.29 21:51:02.494 3: HM485d: Rx: Response: (119) I[0](1,F,B)(38) 42000018 -> 00000001 [5] 69(i) 09C8 {EDD6}
2020.10.29 21:51:02.497 5: SW: fd420000181900000001028170
2020.10.29 21:51:02.499 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000018 [2] {8170}
2020.10.29 21:51:02.500 4: HM485d: Tx: FD067772386909C8
2020.10.29 21:51:22.518 4: HM485d: Rx: FD02784B
2020.10.29 21:51:22.519 4: HM485d: Tx: FD03786100
2020.10.29 21:51:42.543 4: HM485d: Rx: FD02794B
2020.10.29 21:51:42.544 4: HM485d: Tx: FD03796100
2020.10.29 21:52:02.568 4: HM485d: Rx: FD027A4B
2020.10.29 21:52:02.569 4: HM485d: Tx: FD037A6100
2020.10.29 21:52:22.576 4: HM485d: Rx: FD027B4B
2020.10.29 21:52:22.577 4: HM485d: Tx: FD037B6100
2020.10.29 21:52:42.601 4: HM485d: Rx: FD027C4B
2020.10.29 21:52:42.602 4: HM485d: Tx: FD037C6100
2020.10.29 21:53:02.625 4: HM485d: Rx: FD027D4B
2020.10.29 21:53:02.626 4: HM485d: Tx: FD037D6100


Die Einträge ab "2020.10.29 21:51:02.500" sehe ich nirgends anders, ist das die Kommunikation von FHEM zum  HM485d ?

Eigentlich scheint alles in Ordnung zu sein, warum wird der Status von FHEM nicht angezeigt?
Gruß
Michael
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -

loetmeister

#5
Hi Michael,

stimmt das passt alles... FHEM versteht es nicht, da der frame typ fehlt. :)
Hatte mir die XML vorher nicht so genau angeschaut...

Das müsstest du noch in der XML ergänzen:
<frame id="STATE_LEVEL" type="#i" channel_field="10" direction="from_device" event="true">
<parameter size="1.0" index="11.0" type="integer" param="STATE"/>
</frame>



PS: Und nicht wundern, wenn die Standard Laufzeiten nicht passen.... in der XML seht 50 Sekunden, im code nur 20.
Hab ich geändert... https://github.com/loetmeister/HBWired/commit/e8d89032960da6a70ca52d57753f5419e5878e85
Ist aber nicht tragisch.... die Zeiten muss man ja für den Rollo sowieso anpassen.

Gruß,
Thomas

Funsailor

#6
Hi Thomas,
der frame ist ab Zeile 47 in der XML schon drin....
Gruß
Michael

Edit:Die Konfiguration des dazugehörigen Schalter Channel angehängt

Edit2: Hatte die falsch XML angeschaut  :-[ :-[

Jetzt geht es .... Ich höre jetzt lieber auf .... und geh schlafen  :-\
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -

loetmeister

Hi,

Schön das es funktioniert.
Das Modul hat ja nun neben den drei rollo Aktoren noch 6 Taster und sensor Eingänge parallel (an den selben Eingängen). Wie, bzw für was nutzt du diese?
Rollo Bedienung und Fensterkontakte?

Gruß,
Thomas

Funsailor

Hi Thomas,
die Eingänge möchte ich für die Rollosteuerung benutzen. Die Sensoreingänge habe ich parallel gelegt um den Zustand der Schalter abfragen zu können.
Ich bediene zur Zeit die Rolladensteuerung mit Schaltern, das möchte ich beibehalten. Bei der Terassentür möchte ich dann z.B.: den Status nutzen um zu verhindern, das der Rolladen schließt wenn ich im Garten bin.

Gruß
Michael
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -

loetmeister

Hi Michael,

klingt vernünftig vorhandene Schalter zu nutzen. :)

Ich hatte überlegt HBWKey.h eine Ähnliche get() Funktion, wie HBWSenSC.h hinzuzufügen. Dann braucht man keine zusätzlichen Kanäle um den Status der Schalter abzufragen. In deinem Fall wäre das ja völlig ausreichend.
HBWSenSC.h würde man nur einbinden wenn man Notify Meldungen bei den Kanälen braucht.

Gruß,
Thomas

Funsailor

Hallo Thomas,
es geht zwar auch mit Senc, aber das in die Key einzubinden macht einiges einfacher. Und in der Darstellung der HM485 Devices fällt auch einiges weg.
Was mir beim rumsielen aufgefallen ist:
Schalter steht z.B.: nach oben, Rolladen läuft nach oben.
Ich kann den Rolladen aber immer über FHEM steuern, d.H.: Stoppen,  nach unten laufen lassen etc...
Kann man das nicht unterbinden? Z.B.: eine weitere Einstellung in der Channel Configuration...
"if_active_no_commands_allowed"     "no/yes" 
Standart "no"

Ansonsten muss man das in FHEM machen...

Ich werde mir morgen mal die HBWKey und HBWired genauer anschauen...
Gruß
Michael



- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -

loetmeister

Hi Michael,

hab das mal eingebaut...
https://github.com/loetmeister/HBWired/commit/973ad47e7d417b2f45df7a99ae8f6ec3d7670bd3

parameter id="SENSOR" muss der XML im paramset type="VALUES" der Taster (key) Kanäle hinzugefügt werden:


<channel index="7" type="KEY" count="...

...<paramset type="VALUES" id="hbw_input_ch_values">
<parameter id="PRESS_SHORT" operations="event" loopback="true" control="BUTTON.SHORT">
<logical type="action"/>
<physical type="integer" interface="command" value_id="COUNTER">
<event frame="KEY_EVENT_SHORT"/>
</physical>
<conversion type="action_key_counter" counter_size="6" sim_counter="SIM_COUNTER"/>
</para...

<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean" default="false"/>
<physical type="integer" interface="command" value_id="STATE">
<get request="LEVEL_GET" response="INFO_LEVEL"/>
<event frame="INFO_LEVEL" auth_violate_policy="reject"/>
</physical>
</parameter>


Wenn du lust hast kannst du die geänderte HBWKey Lib ja mal testen.

https://github.com/loetmeister/HBWired/tree/master/libraries/src
libraries/src/HBWKey.cpp
libraries/src/HBWKey.h


Gruß,
Thomas

Funsailor

Hallo Thomas,
ich habe das mal ausprobiert, bekomme den State leider nicht rein....

Im Log sehe ich folgendes:

2020-11-08 17:21:38 HM485 HBW_LC_Bl_3_HBW7296280_05 press_long: 1
2020-11-08 17:21:38 HM485 HBW_LC_Bl_3_HBW7296280_05 press_long_1
2020-11-08 17:21:39 HM485 HBW_LC_Bl_3_HBW7296280_11 sensor: closed
2020-11-08 17:21:39 HM485 HBW_LC_Bl_3_HBW7296280_11 sensor_closed
2020-11-08 17:21:42 HM485 HBW_LC_Bl_3_HBW7296280_05 press_short: 2
2020-11-08 17:21:42 HM485 HBW_LC_Bl_3_HBW7296280_05 press_short_2
2020-11-08 17:21:43 HM485 HBW_LC_Bl_3_HBW7296280_11 sensor: open
2020-11-08 17:21:43 HM485 HBW_LC_Bl_3_HBW7296280_11 sensor_open
2020-11-08 17:21:44 HM485 HBW_LC_Bl_3_HBW7296280_01 level: 5
2020-11-08 17:21:44 HM485 HBW_LC_Bl_3_HBW7296280_01 direction: none
2020-11-08 17:21:44 HM485 HBW_LC_Bl_3_HBW7296280_01 working: off
2020-11-08 17:21:44 HM485 HBW_LC_Bl_3_HBW7296280_01 level_5
2020-11-08 17:21:44 HM485 HBW_LC_Bl_3_HBW7296280_04 press_long: 1
2020-11-08 17:21:44 HM485 HBW_LC_Bl_3_HBW7296280_04 press_long_1
2020-11-08 17:21:45 HM485 HBW_LC_Bl_3_HBW7296280_10 sensor: closed
2020-11-08 17:21:45 HM485 HBW_LC_Bl_3_HBW7296280_10 sensor_closed
2020-11-08 17:21:45 HM485 HBW_LC_Bl_3_HBW7296280_04 press_short: 2
2020-11-08 17:21:45 HM485 HBW_LC_Bl_3_HBW7296280_04 press_short_2


Sensor open und closed werden über den Sensor - Channels (11 und 10) gesendet.

Hier noch der Auszug aus dem HMWLOG:

2020.11.08 17:21:38.589 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 040007 {5196}
2020.11.08 17:21:38.591 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B040007
2020.11.08 17:21:39.530 3: HM485d: Rx:  I[0](0,Y,F,B)(98) 42000018 -> 00000001 [5] 69(i) 0A00 {C7EA}
2020.11.08 17:21:39.532 5: SW: fd420000181900000001028170
2020.11.08 17:21:39.534 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000018 [2] {8170}
2020.11.08 17:21:39.535 4: HM485d: Tx: FD0E0065000000019842000018690A00
2020.11.08 17:21:42.190 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 04000A {818C}
2020.11.08 17:21:42.191 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B04000A
2020.11.08 17:21:43.129 3: HM485d: Rx:  I[0](0,Y,F,B)(98) 42000018 -> 00000001 [5] 69(i) 0AC8 {8662}
2020.11.08 17:21:43.132 5: SW: fd420000181900000001028170
2020.11.08 17:21:43.134 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000018 [2] {8170}
2020.11.08 17:21:43.135 4: HM485d: Tx: FD0E0065000000019842000018690AC8
2020.11.08 17:21:44.212 3: HM485d: Rx:  I[0](0,Y,F,B)(98) 42000018 -> 00000001 [6] 69(i) 000A00 {A1CC}
2020.11.08 17:21:44.214 5: SW: fd420000181900000001028170
2020.11.08 17:21:44.217 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000018 [2] {8170}
2020.11.08 17:21:44.218 4: HM485d: Tx: FD0F006500000001984200001869000A00
2020.11.08 17:21:44.483 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 030007 {2F64}
2020.11.08 17:21:44.484 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B030007
2020.11.08 17:21:45.424 3: HM485d: Rx:  I[0](0,Y,F,B)(98) 42000018 -> 00000001 [5] 69(i) 0900 {F18C}
2020.11.08 17:21:45.427 5: SW: fd420000181900000001028170
2020.11.08 17:21:45.429 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000018 [2] {8170}
2020.11.08 17:21:45.430 4: HM485d: Tx: FD0E0065000000019842000018690900
2020.11.08 17:21:45.710 3: HM485d: Rx:  I[0](3,Y,F,B)(F8) 42000018 -> FFFFFFFF [6] 4B(K) 03000A {FF7E}
2020.11.08 17:21:45.711 4: HM485d: Tx: FD0F0065FFFFFFFFF8420000184B03000A
2020.11.08 17:21:45.997 3: HM485d: Rx:  I[0](0,Y,F,B)(98) 42000018 -> 00000001 [6] 69(i) 0F03FF {CCDC}
2020.11.08 17:21:46.000 5: SW: fd420000181900000001028170

Die aktuelle XML Datei habe ich angehängt

Gruß
Michael
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -

loetmeister

Hi,

sorry, war ein Schnellschuss...  ???  aber sagen wir mal so... es war viel richtiges dabei  ;D
Jetzt noch mal ordentlich.

in der XML müsste es lauten:

<channel index="7" type="KEY" count="...
...
<paramset type="VALUES" id="hbw_input_ch_values">
...
<parameter id="SENSOR" operations="read,event" control="DOOR_SENSOR.STATE">
<logical type="boolean" default="false"/>
<physical type="integer" interface="command" value_id="LEVEL">
<get request="LEVEL_GET" response="INFO_LEVEL"/>
<event frame="INFO_LEVEL" auth_violate_policy="reject"/>
</physical>
</parameter>


oder die Konfiguration vom type="SENSOR" mit frame="STATE_LEVEL" - sollte beides gehen.

dazu noch mal die aktuellen
libraries/src/HBWKey.cpp
libraries/src/HBWKey.h

https://github.com/loetmeister/HBWired/tree/master/libraries/src

Funsailor

Hallo Thomas,
kein Problem, ich bin ja froh das du so schnell reagiert hast.  :)

Funktioniert soweit gut, aber ich muss "get State" absetzen um den Status angezeigt zu bekommen.


2020.11.10 17:24:31 5: HBW_LC_Bl_3_HBW7296280: HM485_SendCommand: 5303
2020.11.10 17:24:31 4: hm485: hm485: TX: (117) I[0](0,F,B)(18) 00000001 -> 42000018 [4] 53(S) 03
2020.11.10 17:24:31 5: HBW_LC_Bl_3_HBW7296280: HM485_DoSendCommand: hmwId = 42000018 data = 5303 requestId = 117
2020.11.10 17:24:31 5: HBW_LC_Bl_3_HBW7296280: Device:convertFrameDataToValue: deviceKey = HBW_LC_BL3_IN6 valId = level value1 = 200
2020.11.10 17:24:31 5: HBW_LC_Bl_3_HBW7296280: Device:convertFrameDataToValue: value2 = 200
2020.11.10 17:24:31 5: HBW_LC_Bl_3_HBW7296280: HM485_ProcessChannelState: hmwId = 42000018 Channel = 04 msgData = 6903C8 actionType = response


Aber bei den HMW_LC_BL1_DR wird der Status überhaupt nicht gesendet! Bei den Original Device gibt es nur press_short_xy und press_long_xy

Gruß
Michael
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.50 -