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?
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
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
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
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
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
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 :-\
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
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
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
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
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
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
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
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
Hi Michael,
ja, das ist richtig. Den Status "sensor_open/sensor_closed" erhält man nur per Abfrage... wie gesagt:
ZitatHBWSenSC.h würde man nur einbinden wenn man Notify Meldungen bei den Kanälen braucht.
Es sind ja noch immer "Key" Kanäle, deren eigentliche Verwendung nicht beeinträchtigt werden soll. Der Status ist nur ein kleines Extra. 8)
Zitat von: Funsailor am 10 November 2020, 18:56:36
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
Ja, das ist richtig. Die Funktion ist kein Standard.... :)
Daher hatte ich auch direkt ein
#define ENABLE_SENSOR_STATE // allow to query key channels as SENSOR (returns DOOR_SENSOR.STATE - open/closed) in
HBWKey.h hinzugefügt, da kann man es deaktivieren falls es stört. Würde es auch erst mal als Standardeinstellung aktiv lassen. Ich sehe aktuell kein Problem, da es ja eine passive Funktion ist.
Gruß,
Thomas
Hallo,
ich habe jetzt endlich ein abgespecktes Device ( HBW-LC-BL-1-In2) in Betrieb. Funktioniert seit 3 Wochen fast einwandfrei.
Allerdings habe ich nach einer Woche Dauerbetrieb (WDT) ohne Eingriffe (War eine Woche unterwegs) festgestellt, das die Rollläden nicht mehr Synchron waren. Ich habe dann nochmals getestet und gesehen das es schon nach drei Verstellungen zu Abweichungen kommt. Dummerweise kann ich dann das Fliegengitter der Terrasse nicht mehr öffnen und muss ein wenig herumspielen bis die Endstellung "Oben" richtig angefahren wird.
Wie sind eure Erfahrungen mit den HBW Blind Device? Habt Ihr ähnliche Probleme? Die Zeiten habe ich mit der Stoppuhr gemessen und eingestellt, die Umkehrzeit (change_over_delay) habe ich abgeschätzt auf Min (0.5) gesetzt.
Was mir gleich am Anfang aufgefallen ist: Es gibt eine merkliche Verzögerung vom bedienen der Schalter bis der Rollladen reagiert. Die Schalter sind direkt an den Devices angeschlossen und mittels Peering verknüpft. Die Up Down Channel sind als Doorsensor konfiguriert, die long_press_time auf Min (0.4 s) gesetzt.
Test halber habe ich die Min Zeit in der .M Datei auf 0.1 gesetzt, das hat aber nichts geändert. Liegt wahrscheinlich an den Umschaltzeiten der Relais.
Hi,
Die Laufzeiten (Auf/Ab) für die Rollo Kanäle gelten für die Relais Schaltzeit - wenn dein Rollo etwas länger braucht bis der Motor anläuft, dann müsstest du das in den Laufzeiten oder change_over_delay berücksichtigen.
Bzgl. der HBWKey.h Kanäle. Beim Typ "Doorsensor" wird long_press_time nicht beachtet. Da sind feste debounce Zeiten hinterlegt. Der Typ ist als Sensor für Fenster o.ä. gedacht, nicht für Bedienelemente. Für Rollo Schalter/Taster solltest du besser "Pushbutton" oder "Switch" nutzen.
ZitatTest halber habe ich die Min Zeit in der .M Datei auf 0.1 gesetzt
.M Datei? Was hast du wo genau geändert? ???
Gruß,
Thomas
Hi....
Upps . da fehlt ein p... -> *.pm (Genauer: In der HBW-LC-BL-1-In2.pm Datei) und ein Restart FHEM gemacht. Dann konnte ich den Wert in der Maske auf 0.1 setzen... Ob das Device das anstandslos geschluckt hat ::) keine Ahnung.
Wenn ich die long_press_time z.B.: auf 1.0 verändere wird die Verzögerung merklich länger. Ich teste das aber nochmals genauer wenn ich wieder vor Ort bin.
-> Bei meiner Tastatur klemmt das p.. ??? und beim Durchlesen der Antwort ist mir das nicht aufgefallen :-[
Die Rollos selbst laufen sofort an, ich hatte vorher eine Relaisbox eingesetzt (Die lief jetzt über 25 Jahre ohne Probleme) die ich mit Schaltern (12V) gesteuert hatte. Das ging immer sehr direkt, Schalter umgelegt, Rollos laufen an.
Bei den Schaltern möchte ich bleiben, damit will ich z.B.: den Status der Schalter abfragen und wenn die auf ,,AUF" stehen darf der Rollladen durch die Automatik nicht runtergehen.... Ansonsten könnte ich mich auf der Terrasse aussperren. Mit diesen Infos hattest du mir vorgeschlagen, den Schalter als ,,Doorsensor" zu nutzen. Funktioniert ja auch prima.
Werde aber das Thema "Pushbutton" oder "Switch" zuhause nochmals testen und berichten ... Ich bin der Meinung, das da irgendetwas anderes nicht ging.
Hi Michael,
ok, hab nochmal den Thread überflogen.... das mit den Schaltern und Sperrfunktion hatte ich nicht mehr in Erinnerung. :D Was sind das denn genau für Schalter? Auf, Ab und Mittelstellung?
In den *.pm Dateien sollte man eigentlich nichts ändern, die werden ja aus den Device XML automatisch erzeugt.
long_press_time kannst du ändern, wird wie gesagt aber nur für PUSHBUTTON benutzt. DOORSENSOR hat feste Zeiten "DOORSENSOR_DEBOUNCE_TIME = 330; // ms"
330 ms sind aber eigentlich auch nicht so die große Verzögerung...
Sperren kannst du einen Kanal auch mit "inhibit". Dann sind alle peerings gesperrt. Ansteuerung über FHEM geht aber weiterhin.
PS: Was ich noch nicht verstanden habe, was hat die Verzögerung bei Schalten mit den Rollo Laufzeiten zu tun? ???
PPS: Was meinst du eigentlich mit?
Zitatdas die Rollläden nicht mehr Synchron waren
Die Positionen mehrerer Rollos was unterschiedlich? Oder es passte nicht mehr zu der Schalterstellung?
Gruß,
Thomas
Hi Thomas,
bin heute leider nicht zm testen gekommen, hatten Vorbesprechung für den nächsten Segeltörn :)
Ja, einfache Schalter Auf - Neutral - Ab
Ich hatte die Zeit (0.4 -> 0.1) zuerst in der XML Datei geändert, die PM Datei umbenannt und dann einen Restart von FHEM gemacht. Dachte das beim Neustart alles neu geladen wird und nicht vorhandene pm Dateien erzeugt werden.... zum Glück hatte ich die simple.xml nicht im Verzeichnis, ansonsten hätte FHEM die vorhanden Definitionen mit Simple angelegt... :-[
Darauf bin ich den Weg des geringsten Widerstand gegangen, 8) habe die PM Datei wieder hergestellt und dort die 0.1 eingetragen....
330ms Entprellungszeit ist ja ziemlich lang, in unseren Steuerungen prüfen wir die Signale im 5 ms Raster. Wenn sich ein Eingangs - Signal nach einer Änderung innerhalb von 5 ms ändert, wird die Zeit neu angetriggert, steht das Signal länger als 25 ms an wird es aktzeptiert. Ein Eingangfilter beseitigt Störimpulse. Das Verfahren haben wir mit aufwendigen Tests gut abgeklopft.
Bis der Rollo losläuft kann man bis einundzwa.... "zählen", also etwas länger als eine halbe Sekunde.
Ich will nicht die peerings sperren sondern die Steuerung der Rollos über FHEM verhindern wenn die Schalter in der Stellung "Auf" stehen.
ZitatPS: Was ich noch nicht verstanden habe, was hat die Verzögerung bei Schalten mit den Rollo Laufzeiten zu tun?
-> Nichts, habe ich so nicht sagen wollen.
das die Rollläden nicht mehr Synchron waren-> Die Enstellungen wurden nicht mehr richtig angefahren.
Ich hatte die Rolllos 1 Woche nur im automatischen Betrieb gehabt (Nachts ganz unten).
Als ich wieder daheim ware wollte ich einen Rollo ganz öffnen, er wurde aber nicht mehr ganz nach oben gefahren
Erst nach mehreren Ab - Auf fahrten war der Rollo ganz oben. Seltsamerweise habe ich den Rollo immer nur ein Stückchen runter gefahren.
Ich denke das liegt an der Umschaltzeit, die muss ich etwas Verlängern.
Ich bin davon ausgegeangen, das die Laufzeit ab dem Schalten der Relais beginnt... die Motoren laufen dann sofort an.
Gruß
Michael
Hi,
eine halbe Sekunde könnte passen...
HBWKey: DOORSENSOR_DEBOUNCE_TIME = 330
+
HBWBlind: #define BLIND_WAIT_TIME 200
530ms die min. vergeht, vom betätigen des Schalters, bis das Relais dem Motor den Strom zuschaltet.
Wenn das zu lange ist, dann reduziere DOORSENSOR_DEBOUNCE_TIME doch mal auf ~80ms?
BLIND_WAIT_TIME würde ich so lassen, da es auch die Wartezeit für den Richtungswechsel bestimmt... wenn der Motor selbst nicht den Stillstand abwartet fliegt dir sonst eventuell der Motor aus der Halterung :)
Bzgl. Fahrtzeiten... danke für die Erklärung. :)
Bei einer kompletten Fahrt Auf/Zu bzw. dem anfahren von 0% oder 100% wird noch einmal eine extra Sekunde dazu gerechnet (BLIND_OFFSET_TIME), um auch wirklich in der Endposition anzukommen.
Wenn selbst das nicht reicht, dann sind deine Zeiten eventuell zu knapp Konfiguriert.
Gruß,
Thomas
Zitat von: Funsailor am 10 August 2021, 23:51:53
Erst nach mehreren Ab - Auf fahrten war der Rollo ganz oben. Seltsamerweise habe ich den Rollo immer nur ein Stückchen runter gefahren.
Ich denke das liegt an der Umschaltzeit, die muss ich etwas Verlängern.
Ich bin davon ausgegeangen, das die Laufzeit ab dem Schalten der Relais beginnt... die Motoren laufen dann sofort an.
Hallo Michael,
falls es noch interessant ist... ich habe ein paar kleine Änderungen an der Rollo Library vorgenommen.
Die BLIND_WAIT_TIME von 200 ms auf 100 ms reduziert.
Eine neue Option "MOTOR_STARTUP_DELAY" hinzugefügt. Da kann man nun für jeden Kanal die Anlaufzeit des Motors einstellen. Diese Zeit geht dann nicht von der Fahrtzeig ab und die Position sollte sich dann nicht mehr verschieben. (meine Motoren brauchen ca. eine halbe Sekunde bis sie sich bewegen, nachdem die Spannung anliegt)
Du müsstest deine XML anpassen:
https://github.com/ThorstenPferdekaemper/HBWired/commit/107964a64956c53d4d915d0a8d82fb9b7c300c6c#diff-3031c045e4ee527bbea161154771569dbe8f08962825147a8308388a3d09081b
und die aktuellen Dateien von GitHub laden um deine firmware neu zu Kompilieren. Es sieht nach vielen Änderungen aus, sind aber wirklich nur die beiden erwähten Punkte. ;) (peerings und andere Einstellungen bleiben vorhanden. Das EEPROM Layout hat sich nicht geändert)
libraries/src/HBWBlind.cpp
libraries/src/HBWBlind.h
libraries/src/HBWLinkBlindSimple.h
libraries/src/HBWLinkBlindSimple.hpp
https://github.com/ThorstenPferdekaemper/HBWired/commit/107964a64956c53d4d915d0a8d82fb9b7c300c6c#diff-d96ca9088ed9690fa513189741fd53463e86af758eab312d291a9f9dd896d0bb
Gruß,
Thomas