HM-LC-Bl1PBU-FM Gruppenschaltung über Trennrelais

Begonnen von Jasimo, 30 Juni 2018, 14:13:23

Vorheriges Thema - Nächstes Thema

Jasimo

Hallo,

ich habe zwei HM-LC-Bl1PBU-FM Funk-Rollladenaktoren im Einsatz die jeweils das EG und OG über Trennrelais steuern.
Ich kann also "nur" eine ganze Etage mit den Rolladenaktoren steuern. An jedem Rolladen ist noch eine manuelle Steuermöglichkeit vorhanden, soweit so gut.
Nun habe ich ein kleines Problem, welches sich wie folgt darstellt:
Wenn das z.B. gesammte EG durch ein doif (Zeitsteuerung) geschlossen wurde und ich an einem Rolladen lokal doch wieder eine Öffnung vollziehe, bekommt das ja der Rolladenaktor logischerweise nicht mit. Wenn ich dann aber an dem Rolladenaktor nochmal auf runter drücke fährt er nur ein paar Zentimeter und stoppt wieder. Das hat wohl damit etwas zu tun, dass der Rolladenaktor denkt es ist schon alles zu und von der einen manuellen Öffnung eines Rolladen nichts mitbekommen hat.
Hat jemand eine Idee, wie ich den Rolladenaktor dazu überreden kann nochmal eine komplette Zu-Fahrt zu machen? Eine Verlängerung der Fahrzeiten über z.B.
set <name> regSet driveDown 60.0hat leider keinen Erfolg gebracht.
Gruß
Jan

Otto123

Hallo Jan,

das Problem gab es auch schon mal :) leider ohne wirkliche Lösung aber immerhin ein Ansatz.

https://forum.fhem.de/index.php/topic,81226.msg733022.html#msg733022

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jasimo

Hallo Otto,

ja der von Dir verlinkte Beitrag ist exakt mein Problemchen. Nun, das schaut ja dann nicht so gut aus.
In meinem doif könnte ich es ja so lösen das ich vier mal hintereineander ein up oder down mache mit einem kleinen wait dazwischen.
Dann wären die Unterschiede der Rolladen wieder ausgeglichen.
Der Rolladenaktor hat ja zig Register die man ändern kann, dachte es gibt vielleicht etwas das er "immer" die eingestellte Zeit fährt egal welche Position er hat.
Gruß
Jan

Otto123

Hallo Jan,

Du kannst die Idee von Frank mit dem virtuellen peeren versuchen. Es geht ja darum, dass der lange Tastendruck auf den echten Taster ja genau das tut was Du brauchst.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jasimo

#4
Ja das müsste ich mir mal ansehen mit dem langen Tastendruck. Aber von virtuellen Peeren hab ich noch keinen Plan, da müsste ich erstmal suchen wir sowas geht.
Ich mache mich mal dran die Tage.
Danke für Deine Hilfe!


Gesendet von iPhone mit Tapatalk Pro

Otto123

Naja, wenn Du eine VCCU hast, nimmst Du einfach dort einen virtuellen Kanal. Zum Lesen findest Du genug im Wiki, ansonsten frage einfach nach :)

Schönes Wochenende
Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jasimo

Vccu hab ich schonmal, ziehe ich mir die Tage rein. Danke nochmals.


Gesendet von iPhone mit Tapatalk Pro

Jasimo

#7
Wollte mich nochmal zurück melden und brauche Hilfe ;-)
Habe nun in meiner VCCU virtuelle Channels definiert und zwei davon mit meinem Rolladenaktor gepeert.
Ich hab nun auch die Schaltflächen bei den VCCU Channles in FHEMWeb für press short und press long. Versuche ich nun ein press long fährt der vorher manuell gefahrene Rolladen der Gruppe 1Sek, was dem default von press long entspricht. Das klappt alles.

Nur bekomme ich es irgendwie nicht hin den press long zu verlängern, ein Versuch mit:
set VCCU_Btn1 press long 40bewirkt leider nicht das der press long 40Sek andauert, sondern das der Befehl 40Sek verzögert ausgeführt wird,laut CommandRef soll der press Befehl folgedermassen formatiert werdenpress [long|short] [<peer>] [<repCount>] [<repDelay>]

    simulates button press for an actor from a peered sensor. will be sent of type "long".
    [long|short] defines whether long or short press shall be simulated. Defaults to short
    [<peer>] define which peer's trigger shall be simulated.Defaults to self(channelNo).
    [<repCount>] Valid for long press only. How long shall the button be pressed? Number of repetition of the messages is defined. Defaults to 1
    [<repDelay>] Valid for long press only. defines wait time between the single messages.


repCount wäre wohl die Verlängerung, nur wie gebe ich das in die Kommando zeile ein, mache ich das falsch?
Einset VCCU_Btn1 press long 40 1 bewirkt auch nur eine Verzögerung um 40Sek
Gruß
Jan

Otto123

Hallo Jan,

der syntax der Kommandos ist meist so, das in der Reihenfolge von hinten her die Standardwerte weggelassen können, aber nicht einfach mittendrin.
Ich würde press [long|short] [<peer>] [<repCount>] versuchen. Jetzt musst Du mit der Angabe peer experimentieren. Such mal in der commandref nach "press long" und dort in der Nähe.
Wenn ich die Doku richtig verstehe, sollte self01 oder self02 gehen. Das sind die internen Tasten.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jasimo

#9
Ja genau self01 und self02 passt (glaube ich) nur leider führt einset VCCU_Btn4 press long self01 40 nur zu einer 1Sek fahrt.
Register ändern an dem HM-LC-Bl1PBU-FM muss ich ja nicht oder?
Gruß
Jan

frank

ich schaue grundsätzlich in fhem.log, wenn etwas nicht funktioniert. ist nichts zu erkennen, drehe ich verbose am hauptdevice und channel hoch.

deine hardware installation scheint mir aber auch suboptimal zu sein. um einen rollo zu schliessen, quälst du alle weiteren motoren der etage, da die rollos bereits am anschlag sind.

warum fährst du den offenen nicht wieder einzeln zu? die position der einzelnen rollos kann fhem ja wohl auch nicht erkennen.

wäre es dann nicht motorschonender erst alle rollos auf zu fahren und anschliessend zu?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Jasimo

#11
Hallo Frank.

die Rollos der Gruppe die z.B. schon unten/oben sind werden durch den Befehl nicht nochmals gequält, dafür sorgen die Warema Trennrelais.
Wenn die in Endlage sind, zieht das Relais garnicht erst an. Du hast aber Recht ich könnte das einzelne Rollo auch manuell wieder gerade ziehen oder wie von Dir vorgeschlagen alle Rollos zu und dann erst wieder auf. Aber vielleicht geht es ja doch irgendwie anders ;-)

Hier ein log nach absetzen des Befehls:
2018.07.01 11:24:09 4: WEB_192.168.2.109_49500 POST /fhem&detail=VCCU_Btn4&dev.setVCCU_Btn4=VCCU_Btn4&fwcsrf=csrf_102707473550826&cmd.setVCCU_Btn4=set&arg.setVCCU_Btn4=press&val.setVCCU_Btn4=long+self01+40; BUFLEN:0
2018.07.01 11:24:09 5: Cmd: >set VCCU_Btn4 press long self01 40<
2018.07.01 11:24:09 5: CUL_HM Rollo_EG protEvent:CMDs_pending pending:1
2018.07.01 11:24:09 5: TSCUL_Write: CUL1 sending As0BA0A4404711475F0F934420
2018.07.01 11:24:09 4: TSCUL_send:  CUL1  007273                 As 0B A0 A440 471147 5F0F93 4420
2018.07.01 11:24:09 4: TSCUL_XmitDlyHM:  CUL1  id:5F0F93 rtoms:2328
2018.07.01 11:24:09 5: CUL_HM Rollo_EG protEvent:CMDs_processing... pending:0
2018.07.01 11:24:09 5: Starting notify loop for VCCU_Btn4, 1 event(s), first is set_press long self01 40
2018.07.01 11:24:09 5: createNotifyHash
2018.07.01 11:24:09 5: BatterieStatus: not on any display, ignoring notify
2018.07.01 11:24:09 5: End notify loop for VCCU_Btn4
2018.07.01 11:24:09 3: CUL_HM set VCCU_Btn4 press long self01 40
2018.07.01 11:24:09 5: TSCUL_Read CUL1: /AAF103090811F3020BA0A4404711475F0F93442080
2018.07.01 11:24:09 4: TSCUL_Parse: CUL1  007322 A F103 02115532 02 0B A0 A440 471147 5F0F93 4420 _CCAdly:8
2018.07.01 11:24:09 4: WEB_192.168.2.109_49500 GET /fhem?detail=VCCU_Btn4&fw_id=; BUFLEN:0
2018.07.01 11:24:09 4: WEB: /fhem?detail=VCCU_Btn4&fw_id= / RL:5227 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2018.07.01 11:24:09 5: TSCUL_Read CUL1: /AF10109081219000EA080025F0F934711470101C8003030
2018.07.01 11:24:09 4: TSCUL_Parse: CUL1  007432 A F101 02115684 00 0E A0 8002 5F0F93 471147 0101C80030 -50dB
2018.07.01 11:24:09 5: CUL1: dispatch A0EA080025F0F934711470101C80030::-50:CUL1:
2018.07.01 11:24:09 5: CUL_HM Rollo_EG protEvent:CMDs_done
2018.07.01 11:24:09 4: WEB_192.168.2.109_49500 GET /fhem?cmd=%7BReadingsVal(%22VCCU_Btn4%22%2C%22peerChan%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_102707473550826; BUFLEN:0
2018.07.01 11:24:09 5: Cmd: >{ReadingsVal("VCCU_Btn4","peerChan","")}<
2018.07.01 11:24:09 4: WEB: /fhem?cmd=%7BReadingsVal(%22VCCU_Btn4%22%2C%22peerChan%22%2C%22%22)%7D&XHR=1&fwcsrf=csrf_102707473550826 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip

Otto123

Der Gedanke mit dem virtuellen peer war überflüssig. Du hast den Bl1PBU da kannst Du die interne Taste lange drücken (geht beim BL1 nicht).

Ich habe das probiert:
Ich habe  einen Aktor -> RolloAZL (ist ein BL1)
Der ist gepeert mit einer FB -> TasterDIS_Btn_11 und TasterDIS_Btn_12

Wenn ich jetzt das absetzeset RolloAZL press long TasterDIS_Btn_11 30
Fährt der Rolladen kurz ein Stück, macht dann eine Weile Pause (8 sec) und fährt dann 4 - 5 sec

Das macht er auch wenn er schon bei 100 % ist (hört man).

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Jasimo

#13
Danke fürs Helfen, hab gerade mal ein
set Rollo_EG press long VCCU_Btn4 40 versucht, dann fährt er ca. 20 Sek, mehr scheint nicht zu gehen. Zumindest bewirkt ein erhöhen auf z.B. 90 nichts.
Sehe gerade das der HM-LC-Bl1PBU-FM dann den state IOerr hat, da hat sich wohl der CUL weg gehängt.
Gruß
Jan

Jasimo

Ich hab mir mal ein HM-MOD-RPI-PCB bestellt und baue den parallel zum CUL auf den Raspberry.
Binde den dann mit in die VCCU ein und schaue wie es sich damit verhält.
Soll ja eh besser sein ein Produkt vom Hersteller zu nutzen für Homematic als einen CUL.


Gesendet von iPhone mit Tapatalk Pro