Homebrew Devices HBW-LC-BL-3-In6

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

Vorheriges Thema - Nächstes Thema

loetmeister

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

Funsailor

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.

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

loetmeister

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

Funsailor

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.

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

loetmeister

#19
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

Funsailor

#20
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

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

loetmeister

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

loetmeister

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