Z-Wave Anfängerfragen mit Fibaro FGR-223

Begonnen von ronzo, 25 Januar 2023, 16:29:06

Vorheriges Thema - Nächstes Thema

ronzo

Liebe Leute,

ich habe mir ein paar FGR-223 von Fibaro geholt um damit 4 Rolläden und 2 Außenjalousien anzusteuern. Ich bin ganz überrascht wie problemlos die Inklusion geklappt hat und bin erst mal richtig begeistert - im Vergleich zum Zigbee-Zirkus ein wahrer Segen!

Von Beta-User habe ich im Thread https://forum.fhem.de/index.php/topic,129723.msg1242925.html einige Hinweise und wertvolle Anregungen bekommen. Z.B.
ZitatZWave ist sehr viel "schweigsamer", da sprechen nur die Geräte miteinander, denen man jeweils gesagt hat, dass die zusammen gehören (assoziiert sind). Das gilt explizit auch für die Zentrale...
Du musst also einem FGS-223 eben nicht nur mitteilen, zu welchem Netzwerk er gehört (Inklusion), sondern explizit sagen: Berichte alles (auch) an die Zentrale.

Ich habe auch schon festgestellt, dass ich pro FGR-223 in FHEM 3 Devices sehe. z.B.:
ZWave_SWITCH_MULTILEVEL_4
ZWave_SWITCH_MULTILEVEL_4.01
ZWave_SWITCH_MULTILEVEL_4.02

Wozu dienen die drei Devices? Habe schon bemerkt, dass ich die Rolläden über das 01er-Device rauf- und runterfahren kann.

Was passiert nun, wenn ich nur eines der drei Devices in FHEM umbenenne? Ist das egal oder hat das negative Auswirkungen auf die anderen?

Welche rolladenspezifischen Settings muss ich in FHEM hier noch machen? Was ist nötig um bei den beiden Außenjalousien die Lamellenposition einstellen zu können? Usw. usf.

Ich habe auch von AutoShuttersControl gelesen - da muss ich mich aber erst vertiefen.
Bin für jeden Tipp dankbar. Auch wenn er "nur" auf etwas Dokumentation verweist. Bin was z-Wave betrifft erst am Anfang und weiß noch nicht wo ich überall Relevantes finde...

Danke im Voraus für jeglichen Input!

LG
Ronzo

Beta-User

Zitat von: ronzo am 25 Januar 2023, 16:29:06
ich habe mir ein paar FGR-223 von Fibaro geholt um damit 4 Rolläden und 2 Außenjalousien anzusteuern. Ich bin ganz überrascht wie problemlos die Inklusion geklappt hat und bin erst mal richtig begeistert - im Vergleich zum Zigbee-Zirkus ein wahrer Segen!
Die Dinger (bzw. auch deren Vorgänger) sind wirklich schwer ok und haben mit dem "scene-Setter"-feature auch eine erweiterte Funktionalität, die sogar manche Mitbewohnerin nutzt... (Alle Rollläden in einem Raum komplett auf per Doppelklick uä...)

Zitat
Von Beta-User habe ich im Thread https://forum.fhem.de/index.php/topic,129723.msg1242925.html einige Hinweise und wertvolle Anregungen bekommen. Z.B.
Der "bessere" Thread dürfte der hier sein: https://forum.fhem.de/index.php/topic,100390.0.html

Zitat
Ich habe auch schon festgestellt, dass ich pro FGR-223 in FHEM 3 Devices sehe. z.B.:
ZWave_SWITCH_MULTILEVEL_4
ZWave_SWITCH_MULTILEVEL_4.01
ZWave_SWITCH_MULTILEVEL_4.02

Wozu dienen die drei Devices? Habe schon bemerkt, dass ich die Rolläden über das 01er-Device rauf- und runterfahren kann.

Was passiert nun, wenn ich nur eines der drei Devices in FHEM umbenenne? Ist das egal oder hat das negative Auswirkungen auf die anderen?
Das mit den drei Devices ist "normal", ich verwende den (umbenannten) Kanal 1 (ZWave_SWITCH_MULTILEVEL_x.01) zum Steuern der Behanghöhe, über ZWave_SWITCH_MULTILEVEL_x.02 kann die Lamellenposition gesetzt werden.

Zitat
Welche rolladenspezifischen Settings muss ich in FHEM hier noch machen? Was ist nötig um bei den beiden Außenjalousien die Lamellenposition einstellen zu können? Usw. usf.
Das braucht spezielle Einstellungen, die aber (fast alle?) per attrTemplate gesetzt werden können.

Zitat
Ich habe auch von AutoShuttersControl gelesen - da muss ich mich aber erst vertiefen.
Bin für jeden Tipp dankbar. Auch wenn er "nur" auf etwas Dokumentation verweist. Bin was z-Wave betrifft erst am Anfang und weiß noch nicht wo ich überall Relevantes finde...
Das ist alles etwas verstreut, die "Spezialitäten" für ASC sind ggf. über das Wiki und einen weiteren dort verlinkten Thread zu finden, kann auch sein, dass das attrTemplate gleich die passenden Einstellungen macht, damit man auhc im Jaliousiemodus hinreichend saubere Positionen hat für ASC.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

gamauf

#2
Hallo ronzo!

Zum Einstieg in Z-Wave kannst du das lesen:
https://wiki.fhem.de/wiki/Z-Wave

ZWave_SWITCH_MULTILEVEL_4      ist das Haupt-Device
ZWave_SWITCH_MULTILEVEL_4.01   zum Hinauf- und Hinunterfahren
ZWave_SWITCH_MULTILEVEL_4.02   zum Verstellen der Lammellen

Ich habe meine Jalousien so konfiguriert:
Haupt-Device:
defmod ZW_Roller_SZ ZWave XXX
attr ZW_Roller_SZ IODev ZWDongle_0
attr ZW_Roller_SZ classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO TRANSPORT_SERVICE VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL SECURITY SECURITY_S2 METER CONFIGURATION CRC_16_ENCAP ALARM PROTECTION MULTI_CHANNEL CENTRAL_SCENE FIRMWARE_UPDATE_MD APPLICATION_STATUS SUPERVISION
attr ZW_Roller_SZ group Fenster
attr ZW_Roller_SZ neighborListPos 773.66,692.89
attr ZW_Roller_SZ room 19,Schlafzimmer,ZWave
attr ZW_Roller_SZ vclasses ALARM:8 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 CENTRAL_SCENE:3 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:4 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SECURITY_S2:1 SUPERVISION:1 SWITCH_MULTILEVEL:4 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
attr ZW_Roller_SZ webCmd dim

Child 01:

defmod ZW_Roller01_SZ ZWave XXX
attr ZW_Roller01_SZ IODev ZWDongle_0
attr ZW_Roller01_SZ alias Jalousie_SZ
attr ZW_Roller01_SZ classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION METER ALARM APPLICATION_STATUS
attr ZW_Roller01_SZ devStateIcon 1.*:fts_shutter_100 99.*:fts_window_2w 1\d.*:fts_shutter_90 2\d.*:fts_shutter_80 3\d.*:fts_shutter_70 4\d.*:fts_shutter_60 5\d.*:fts_shutter_50 6\d.*:fts_shutter_40 7\d.*:fts_shutter_30 8\d.*:fts_shutter_20 9\d.*:fts_shutter_10 \d.*:fts_shutter_90
attr ZW_Roller01_SZ group Fenster
attr ZW_Roller01_SZ room 19,Schlafzimmer,ZWave
attr ZW_Roller01_SZ stateFormat {my $x = ReadingsVal($name,"state",0);;;; $x =~ s/dim\s//;;;; $x}
attr ZW_Roller01_SZ webCmd d

Child02:
defmod ZW_Roller02_SZ ZWave XXX
attr ZW_Roller02_SZ IODev ZWDongle_0
attr ZW_Roller02_SZ alias Jalousie_Lamellen_SZ
attr ZW_Roller02_SZ classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION APPLICATION_STATUS
attr ZW_Roller02_SZ devStateIcon \d:fts_blade_arc_close_100 [0123]\d:fts_blade_arc_close_100 [456]\d:fts_blade_arc_close_50 [789]\d:fts_blade_arc_close_00
attr ZW_Roller02_SZ group Fenster
attr ZW_Roller02_SZ room 19,Schlafzimmer,ZWave
attr ZW_Roller02_SZ stateFormat {my $x = ReadingsVal($name,"state",0);;;; $x =~ s/dim\s//;;;; $x}
attr ZW_Roller02_SZ webCmd dim
attr ZW_Roller02_SZ widgetOverride dim:knob,min:0,max:99,step:1,angleOffset:-150,angleArc:180,thickness:.2

und damit die alle Devices nach dem Verstellen mit dem Taster an der Wand aktualisiert werden:
defmod ZW_Roller_SZ_notify_1 notify ZW_Roller_SZ:reportedState:.dim.* get ZW_Roller0[12]{1}_SZ swmStatus
attr ZW_Roller_SZ_notify_1 room 19,Schlafzimmer,ZWave


LG
Rainer

ronzo

#3
Wow! Danke für die überaus raschen Antworten! Werde sie mir so bald wie möglich zu Gemüte führen!

ronzo

Zitat von: Beta-User am 25 Januar 2023, 16:47:57
Das mit den drei Devices ist "normal", ich verwende den (umbenannten) Kanal 1 (ZWave_SWITCH_MULTILEVEL_x.01) zum Steuern der Behanghöhe, über ZWave_SWITCH_MULTILEVEL_x.02 kann die Lamellenposition gesetzt werden.

Du hast vermutlich alle drei Devices einheitlich umbenannt, oder?

Zitat von: Beta-User am 25 Januar 2023, 16:47:57
Das braucht spezielle Einstellungen, die aber (fast alle?) per attrTemplate gesetzt werden können.

Wo finde ich mehr zu attrTemplate?

Beta-User

Zitat von: ronzo am 25 Januar 2023, 17:43:25
Du hast vermutlich alle drei Devices einheitlich umbenannt, oder?
Nein. die zwei eigentlich nicht benötigten haben weiter ihren "technischen" Namen.

Zitat
Wo finde ich mehr zu attrTemplate?
Es sollte bei deinem Hauptdevice ein setter sein, über den man zuerst einige Hilfsroutinen runterladen kann, die man dann im Folgenden braucht. Den (allgemeinen) Thread dazu (bzgl. ZWave) müßte ich suchen, sollte aber nicht schwer zu finden sein.

Was im einzelnen jedes Template macht, wird vorher angezeigt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

Perfekt! Danke erstmal! Werde nun zusehen, dass ich meine Wissenslücken fülle. Melde mich wieder..

ronzo

#7
Zitat von: ronzo am 25 Januar 2023, 16:29:06
Ich bin ganz überrascht wie problemlos die Inklusion geklappt hat und bin erst mal richtig begeistert

Das nehm ich gleich wieder zurück...

Wollte heute zwei weitere FGR-223 zu FHEM hinzufügen, bekam aber bei beiden nur ein Device (anstatt 3) angelegt. Und zwar das erste Device, sprich


ZWave_SWITCH_MULTILEVEL_6
ZWave_SWITCH_MULTILEVEL_7


Zusätzlich tauchte dann noch

ZWave_Node_7.1

auf.

Das Removen (Exkludieren) des jeweiligen Devices will auch nicht wirklich funktionieren...

Beide FGR-223, die hiervon betroffen sind, sind die ersten Geräte im Obergeschoss. Die anderen waren alle im EG, wo sich auch der ZWave-Stick befindet. Kann das ein Reichweitenproblem sein?

Beta-User

Etwas mehr Info, was ggf. im Event-Monitor beim Inklusionsversuch zu sehen war wäre schon hilfreich: https://wiki.fhem.de/wiki/Z-Wave#Hinzuf.C3.BCgen_eines_neuen_Z-Wave_Ger.C3.A4ts_.2F_Inklusion. Das klingt danach, als wäre das Auslesen der Geräteinfo nicht vollständig gewesen, kann man ggf. auch wiederholen (bitte den ganzen Wiki-Beitrag intensiv lesen, ich habe das jedenfalls auch alles nicht beim ersten Mal verstanden...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

Für das 7er-Device bekam ich durch

set ZWave_SWITCH_MULTILEVEL_7 mcCreateAll

noch das 02er-Device plus Log angelegt. Das nicht ganz korrekte 01er-Device blieb aber so.

Beim Device ZWave_SWITCH_MULTILEVEL_6 bekomme ich beim mcCreateAll-Versuch allerdings die Fehlermeldung "Timeout reading answer for mcEndpoints".

Beta-User

Zitat von: ronzo am 26 Januar 2023, 13:01:17
Für das 7er-Device bekam ich durch

set ZWave_SWITCH_MULTILEVEL_7 mcCreateAll

noch das 02er-Device plus Log angelegt. Das nicht ganz korrekte 01er-Device blieb aber so.
Soweit klar - bei der Prüfung, ob eine Node bereits da ist, kommt es nur auf die Nummer (Unter-Adresse) an, nicht auf die Benennung.

Zitat
Beim Device ZWave_SWITCH_MULTILEVEL_6 bekomme ich beim mcCreateAll-Versuch allerdings die Fehlermeldung "Timeout reading answer for mcEndpoints".
Das scheint ein Funkproblem zu sein. Falls du es mit der Netzwerkinklusion versucht hattest, solltest du das ZWDongle mal in die Nähe des Aktor bringen und es dann nochmal versuchen.

Evtl. auch mal das Netzwerk optimieren (es müßte dazu afaik einen setter am Dongle-Device geben)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

Ich habe die beiden Nodes nun nochmal excluded und neu included. Der Event-Monitor war hier durchaus hilfreich. Auch wenn ich zu blöd war, auf "ZWave" zu filtern...

Ich habe nun jeweils drei Devices angelegt bekommen. Alles paletti.

Allerdings habe ich nun ein verwaistes 6er-Device und drei verwaiste 7er-Devices in FHEM. Wie werde ich die los? Ein "delete this device" wie ich es von HomeMatic-Devices her kenne, finde ich auf den ersten Blick nicht...

Zum AttrTemplate hätt ich auch noch ne Frage. Auf welches der drei Devices soll ich das FGR-223-Template anwenden? Auf alle drei? Oder nur auf ein bestimmtest? (Habe auch gesehen, dass für meine Außenjalousiene ein VenetianBlind-Template existiert. Das würde ich natürlich dort anwenden. Und die Roller-Templates auf den Rolläden)

Beta-User

"delete" ist in FHEMWEB jetzt (allgemein) im Dropdown-Menü unten zu finden.

Du hast übrigens auch zwei "verwaiste" Plätze auf dem Dongle - ich würde prinzipiell immer versuchen, die Inklusion zu vervollständigen, sonst muss man da wieder nacharbeiten (replace failed node), was aber nicht soooo easy ist.

Der zuerst herunterzuladende Zusatzcode (per attrTemplate möglich) sollte (soweit ich mich entsinne) jeweils automatisch feststellen, wie die Devices zusammengehörigen und dann alle drei miteinander konfigurieren. Bitte testen und ggf. feedback geben.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

Zitat von: Beta-User am 26 Januar 2023, 14:04:24
"delete" ist in FHEMWEB jetzt (allgemein) im Dropdown-Menü unten zu finden.

Danke. Ich muss wieder mehr mit FHEM machen. Bin eingerostet. Aber neben Arbeit und drei Kids fehlt mir oft die Zeit...

Zitat von: Beta-User am 26 Januar 2023, 14:04:24
Du hast übrigens auch zwei "verwaiste" Plätze auf dem Dongle - ich würde prinzipiell immer versuchen, die Inklusion zu vervollständigen, sonst muss man da wieder nacharbeiten (replace failed node), was aber nicht soooo easy ist.

Ups. Daran hatte ich gar nicht gedacht. Manuell werd ich die zwei Plätze auf dem Dongle wohl nicht wieder freigeben können, oder?

Zitat von: Beta-User am 26 Januar 2023, 14:04:24
Der zuerst herunterzuladende Zusatzcode (per attrTemplate möglich) sollte (soweit ich mich entsinne) jeweils automatisch feststellen, wie die Devices zusammengehörigen und dann alle drei miteinander konfigurieren. Bitte testen und ggf. feedback geben.

Danke. Ich werde es ausprobieren!

Beta-User

Zitat von: ronzo am 26 Januar 2023, 15:10:42
Ups. Daran hatte ich gar nicht gedacht. Manuell werd ich die zwei Plätze auf dem Dongle wohl nicht wieder freigeben können, oder?
"Freigeben" paßt nicht so richtig. Man kann händisch bei einer Neuinklusion festlegen, dass so ein Platz (bzw. welcher) genutzt werden soll. Das Verfahren ist halt umständlich, das Stichwort hatte ich schon geschrieben.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

Zitat von: Beta-User am 26 Januar 2023, 14:04:24
Der zuerst herunterzuladende Zusatzcode (per attrTemplate möglich) sollte (soweit ich mich entsinne) jeweils automatisch feststellen, wie die Devices zusammengehörigen und dann alle drei miteinander konfigurieren. Bitte testen und ggf. feedback geben.

Mein erster Versuch auf dem 01er-Device schlug schon mal fehl:
ZitatERROR executing perl-code { FHEM::attrT_ZWave_Utils::identify_channel_devices("ZWave_SWITCH_MULTILEVEL_3.01",0) } for param MAINCHANNEL: Undefined subroutine &FHEM::attrT_ZWave_Utils::identify_channel_devices called at (eval 32538) line 1.

ronzo

Zitat von: Beta-User am 26 Januar 2023, 15:13:30
"Freigeben" paßt nicht so richtig. Man kann händisch bei einer Neuinklusion festlegen, dass so ein Platz (bzw. welcher) genutzt werden soll. Das Verfahren ist halt umständlich, das Stichwort hatte ich schon geschrieben.

Spannend. Der 6er gibt für isFailedNode "true" zurück. Hier ginge es. Beim 7er aber interessanterweise nicht - hier hab ich wohl was verk***t.

Beta-User

Zitat von: ronzo am 27 Januar 2023, 23:02:06
Mein erster Versuch auf dem 01er-Device schlug schon mal fehl:
Hast du denn vorher wie angedeutet das "runterladen"-attrTemplate angewandt?!? (zwave_get_...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

#18
Nö. Dachte das würde implizit passieren. Was ist hier zu tun?

Im Wiki-Artikrl gind ich dazu absolut nichts...

Beta-User

#19
Schau dir einfach die Beschreibungen unter den attrTemplate an, beginnend von oben. Dann wird es hoffentlich klarer (also einfach die dropdown-Liste nacheinander durchscrollen, aber (noch) nicht anwenden.
Das mit dem Code dann schon.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

#20
Ah. Sehe schon. Ich denke du spielst auf das zwave_get_myutils_from_svn an... hat danach wunderbar funktioniert. Könnte man das nicht implizit beim Versuch das attrTemplate anzuwenden aus dem SVN downloaden lassen?

Beta-User

Zitat von: ronzo am 28 Januar 2023, 21:50:08
hat danach wunderbar funktioniert.
:)
Dann hoffe ich mal, dass nicht nur das Anwenden funktioniert hat, sondern auch das Ergebnis deinen Vorstellungen entspricht ;) .

Zitat von: ronzo am 28 Januar 2023, 21:50:08
Könnte man das nicht implizit beim Versuch das attrTemplate anzuwenden aus dem SVN downloaden lassen?
Könnte man schon, man müßte halt sinnvollerweise erst prüfen, ob es schon da ist...

ABER: Das ganze ist im Moment ein proof of concept, der im Moment mehr oder weniger ausschließlich meinen "Zoo" wiederspiegelt. Die Beteiligung bzw. das Interesse von anderen, da mit beizutragen war in etwa genauso groß wie die Zahl derer, die Rückmeldung dazu gegeben haben (0 vs. nahe 0....). Von daher ist dann auch mein Engagement in der Sache etwas zurückgegangen...

Mal sehen.

ZWave erfordert aber immer etwas Einarbeitung, von daher dachte ich, es wäre eine gute Idee, bei den attrTemplate dann wenigstens die essentiellen Fundstellen und Hinweise in der passenden Reihenfolge aufzuzeigen - und da bekommt man ja den Hinweis, dass man den Code holen muss (bzw. kann).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

#22
Ich gebe gerne Rückmeldung und könnte sogar etwas beitragen, da ich des Programmierens mächtig bin - auch wenn mein Perl vielleicht schon etwas eingerostet ist.

Ich habe gestern die attrTemplates FGR-223-RollerMode auf alle Rolläden angewandt. Hat super funktioniert. Bei meinen Außenjalousien hab ich das FGR-223-VenetianBlind-Template angewandt. Da konnte ich dann zwar die Lamellenposition variieren, ein rauf- oder runterfahren der Jalousie war aber nicht mehr möglich. Ich habe aus "Panik" dann einfach das RollerMode-Template auf beide Außenjalousien angewandt. Eine der beiden lässt sich nun wieder schön rauf- und runterfahren. Die andere bewegt sich nun allerdings gar nicht mehr rauf... Hier wäre ein FactorySettings-Template wohl recht praktisch... ;-) Muss mal sehen ob ich das irgendwie hinbekomme...

Ich checke mal die Verkabelung - habe schon festgestellt, dass das S2-Kabel für den Schalter rausgerutscht war. Das hab ich behoben - rauffahren kann ich die Jalousie aber noch immer nicht...

Bin mir auch nicht sicher ob ich überall rauf/runter richtig verkabelt habe. War aufgrund der von der Rolladenfirma verwendeten Kabel nicht durchgängig erkennbar...

Beta-User

Klingt für mich von sehr weit weg nach einem Kalibrierungsproblem. Das solltest du zuerst machen (ich dachte eigentlich, das geht ganz ohne FHEM automatisch).

Jedenfalls sollte es ohne reset klappen, wieder das Jalousie-attrTemplate anzuwenden, jedenfalls dann, wenn du keine händischen Konfigurationsbefehle abgesetzt hattest.

Meine Jalousien steure ich übrigens über Kanal 1 (Behang); kann sein, dass es über das Hauptdevice gar nie geht (falls du das probiert haben solltest).

Ansonsten ist jede Mithilfe gerne gesehen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

#24
Zitat von: Beta-User am 29 Januar 2023, 10:41:33
Klingt für mich von sehr weit weg nach einem Kalibrierungsproblem. Das solltest du zuerst machen (ich dachte eigentlich, das geht ganz ohne FHEM automatisch).

Das könnte durchaus sein. Das initiale Kalibrieren hat eigentlich die Rolladenfirma gemacht. Kann ich das durch mein Herumprobieren verstellt haben? Oder hat die Firma die Endlagenpositionen vielleicht nicht korrekt gespeichert?

Es müsste sich doch nacht dem Ausschlussprinzip herausfinden lassen, oder? Ich hänge den, der nicht rauffahren will, testweise an den benachbarten FGR-223. Wenn das auch nicht funktioniert, muss es ein Problem mit der Einstellung des Rolladenmotors sein.

Beta-User

Die Fa. hat aber vermutlich nicht den Aktor kalibriert, oder? Das muss man zusätzlich machen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

#26
Zitat von: Beta-User am 29 Januar 2023, 13:41:58
Die Fa. hat aber vermutlich nicht den Aktor kalibriert, oder? Das muss man zusätzlich machen...

Nein. Hat sie nicht. OMG! Was ist hier noch zu tun? (Warum funktionieren alle anderen 5 Rolläden/Jalousien problemlos? War das nur pures Glück?) Sind das die Fahrzeiten, die man messen und in FHEM eintragen muss? Oder noch etwas ganz Anderes?

Sorry für meine Unbeholfenheit in dieser Materie. Ich passe aber gut auf und merke mir die Dinge!

Beta-User

Ich weiß auch nicht mehr, wie es geht, aber mit einiger Sicherheit steht es im "Manual" des Herstellers  ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

#28
Danke für deine Geduld! Schon gefunden. Unfassbar wie unbedarft ich an die Sache heranging... : :'(

Die Außenjalousie tut wieder wie sie soll. Nun auch mit dem VenetianBlind-Template.

ronzo

Bei meinen beiden Außenjalousien (Venetian Blind Template) wird interessanterweise bei einer im komplett geschlossenen Zustand "25 %", bei der anderen korrekterweise "0 %" angezeigt. Habe ich hier eine Möglichkeit korrigierend einzugreifen? Wenn ja, wie?

Kann man irgendwo ablesen, ob die Kalibrierungsfahrten bei den anderen Rolläden korrekt durchgeführt worden sind?

Ich nehme an, dass ich die Fahrzeiten der Rolläden/Außenjalousien auch noch wo eintragen muss, wie ich das bei meinen HomeMatic-gesteuerten Markisen vor Jahren gemacht habe?

Beta-User

Vermutlich mußt du die Kalibrierung nochmal anschubsen (bitte suchen, wie es geht...).

Die Dinger erkennen in der Regel am Stromverbrauch, wo Ende ist und stellen dementsprechend ihre Zeiten ein. Man kann das auch manuell machen (afaik), aber das ist nur für sehr spezielle Fälle gedacht...

(Hatte ich schon erwähnt, dass ich diese Aktoren bzw. deren firmware für sehr viel durchdachter halte als die (der) HM-classic...?!?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

Zitat von: Beta-User am 29 Januar 2023, 17:42:18
Vermutlich mußt du die Kalibrierung nochmal anschubsen (bitte suchen, wie es geht...).

Laut Fibaro FGS-223 Anleitung 3x für 3 Sekunden den Auf- oder Ab-Schalter drücken. Dann startet eine Kalibrierungsfahrt. (http://manuals-backend.z-wave.info/make.php?lang=DE&sku=FIBEFGR-223) - werde ich morgen ausprobieren.

Zitat von: Beta-User am 29 Januar 2023, 17:42:18
Die Dinger erkennen in der Regel am Stromverbrauch, wo Ende ist und stellen dementsprechend ihre Zeiten ein. Man kann das auch manuell machen (afaik), aber das ist nur für sehr spezielle Fälle gedacht...

Ich möchte keinen Spezialfall bei mir haben. Lasse morgen/übermorgen nochmal kalibrieren.

Zitat von: Beta-User am 29 Januar 2023, 17:42:18
(Hatte ich schon erwähnt, dass ich diese Aktoren bzw. deren firmware für sehr viel durchdachter halte als die (der) HM-classic...?!?)

Obwohl ich - wie du sicher bemerkt hast - so einige Anfängerschwierigkeiten hatte, bin ich hier voll deiner Meinung. Habe sogar schon darüber nachgedacht, die beiden Markisen künftig auch über ZWave anzusteuern (Problem: Die Aktoren müsste ich in einer UP-Dose im Außenbereich anbringen. Weiß nicht ob sie das wirklich aushalten...)


gamauf

Kalibrierungsfahrt wird so gestartet:
set ZWave_SWITCH_MULTILEVEL_4 configForcedRollerShutterCalibration StartCalibrationProcess
Die Zeit zum Verstellen der Lammelen mußt du selber messen und im Parameter  configVenetianBlindTimeOfFullTurnOfThe152 speichern

ronzo

Besten Dank! Muss ich die "normale" Fahrzeit für rauf und runter auch wo eintragen?

ronzo

Was mir noch nicht zusagt ist, dass die Außenjalousien bei vollem Öffnen (dim 99) ganz rauf in den dafür vorgesehenen Kasten fahren und dann zwei Sekunden später wieder etwas rausfahren (auf dim 96). Wie lässt sich das erklären? Wie werde ich dieses Verhalten los?

Beta-User

Das hängt mit configSetSlatsBackToPreviousPosition zusammen.
Bei mir steht das auf 0 (OnlyInCaseOfTheMainController0). Der Parameter bestimmt, wohin sich die Lamellen nach Abschluss einer Fahrt drehen sollen (je nachdem, von wo aus die Fahrt initiiert wird), Hier bewegen sich die Lamellen jedenfalls  nicht mehr zurück.

Wobei hier die meisten Fahrten sowieso von ASC angewiesen werden, und da habe ich zusätzlich die Lamellenpositionen auch mit festgelegt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ronzo

#36
Zitat von: Beta-User am 30 Januar 2023, 06:40:43
Das hängt mit configSetSlatsBackToPreviousPosition zusammen.
Bei mir steht das auf 0 (OnlyInCaseOfTheMainController0). Der Parameter bestimmt, wohin sich die Lamellen nach Abschluss einer Fahrt drehen sollen (je nachdem, von wo aus die Fahrt initiiert wird), Hier bewegen sich die Lamellen jedenfalls  nicht mehr zurück.

Wobei hier die meisten Fahrten sowieso von ASC angewiesen werden, und da habe ich zusätzlich die Lamellenpositionen auch mit festgelegt.

Vielen Dank! Mit der Info klappt es wunderbar. Ich war ein paar Tage außer Gefecht und deshalb so ruhig... ;-)

Ich frage mich allerdings, ob die AssociationGroups korrekt eingerichtet wurden. Sollten doch mit dem Controller verknüpft worden sein, da es für die FGR-223 ja ein XML gibt. Aber bei der Inklusion hatte ich das ja noch nicht angewendet, da das übers attrTemplate kam, oder?

Wenn ich mir das "Hauptdevice" eines Rolladens exemplarisch ansehe, dann gibt es dort 3 assocGroups (eine mit Platz für 1 Node - das wäre wohl für den Controller und zwei mit Platz für 5 Nodes).

Unter "assotiatedWith" sehe ich allerdings nur die beiden dazugehörigen Devices aber keinen Controller gelistet. Müsste der nicht auch in der Liste auftauchen, wenn ich alles korrekt eingerichtet hätte? (Nebenfrage: Sieht man auch irgendwo in welcher assocGroup sich die unter associatedWith befindlichen Devices befinden? So kann ich ja nur mutmaßen, dass sie vermutlich in Group 2 sind)

ronzo

#37
Zitat von: Beta-User am 30 Januar 2023, 06:40:43
Das hängt mit configSetSlatsBackToPreviousPosition zusammen.
Bei mir steht das auf 0 (OnlyInCaseOfTheMainController0). Der Parameter bestimmt, wohin sich die Lamellen nach Abschluss einer Fahrt drehen sollen (je nachdem, von wo aus die Fahrt initiiert wird), Hier bewegen sich die Lamellen jedenfalls  nicht mehr zurück.

Wobei hier die meisten Fahrten sowieso von ASC angewiesen werden, und da habe ich zusätzlich die Lamellenpositionen auch mit festgelegt.

ASC ist sehr umfangreich (bin begeistert und erschlagen zu gleich). Wie müsste eine einfache Fahrt nach oben plus Lamellenpositionseinstellung beispielsweise aussehen?

Ich habe nun mal ein ASC device angelegt, und auf den beiden Hauptdevices der Außenjalousien das ASC-Attribut auf 1 gesetzt. Danach am ASC-Device ein ScanForShutters ausgeführt. Nun sieht es so aus:

define RaffstoreASC AutoShuttersControl
attr RaffstoreASC ASC_twilightDevice myTwilight
attr RaffstoreASC devStateIcon { ShuttersControl_DevStateIcon($name) }
attr RaffstoreASC icon fts_shutter_automatic
attr RaffstoreASC room ASC
#   .FhemMetaInternals 1
#   CFGFN     
#   FUUID      63f8773a-f33f-88ea-cffc-af3350f8c9c665fc
#   FVERSION   73_AutoShuttersControl.pm:v0.10.25-s26950/2023-01-03
#   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
#   NAME       RaffstoreASC
#   NOTIFYDEV  RaffstoreASC,ZWave_SWITCH_MULTILEVEL_4,ZWave_SWITCH_MULTILEVEL_5,global,myTwilight
#   NR         3360
#   NTFY_ORDER 51-RaffstoreASC
#   STATE      created new drive timer
#   TYPE       AutoShuttersControl
#   VERSION    v0.10.25
#   eventCount 7
#   .attraggr:
#   .attrminint:
#   Helper:
#     DBLOG:
#       ZWave_SWITCH_MULTILEVEL_4_nextAstroTimeEvent:
#         DBLogging:
#           TIME       1677227973.1126
#           VALUE      24.02.2023 - 17:23
#       ZWave_SWITCH_MULTILEVEL_5_nextAstroTimeEvent:
#         DBLogging:
#           TIME       1677227973.12068
#           VALUE      24.02.2023 - 17:23
#       state:
#         DBLogging:
#           TIME       1677227973.12192
#           VALUE      created new drive timer
#       userAttrList:
#         DBLogging:
#           TIME       1677227970.09118
#           VALUE      rolled out
#   READINGS:
#     2023-02-24 09:39:35   .monitoredDevs  {"myTwilight":{"RaffstoreASC":"ASC_twilightDevice"}}
#     2023-02-24 09:39:33   ZWave_SWITCH_MULTILEVEL_4_nextAstroTimeEvent 24.02.2023 - 17:23
#     2023-02-24 09:39:33   ZWave_SWITCH_MULTILEVEL_5_nextAstroTimeEvent 24.02.2023 - 17:23
#     2023-02-24 09:39:30   room_ZWave      ZWave_SWITCH_MULTILEVEL_4,ZWave_SWITCH_MULTILEVEL_5
#     2023-02-24 09:39:33   state           created new drive timer
#     2023-02-24 09:39:30   userAttrList    rolled out
#   helper:
#     shuttersList:
#       ZWave_SWITCH_MULTILEVEL_4
#       ZWave_SWITCH_MULTILEVEL_5
#   monitoredDevs:
#     myTwilight:
#       RaffstoreASC ASC_twilightDevice
#
setstate RaffstoreASC created new drive timer
setstate RaffstoreASC 2023-02-24 09:39:35 .monitoredDevs {"myTwilight":{"RaffstoreASC":"ASC_twilightDevice"}}
setstate RaffstoreASC 2023-02-24 09:39:33 ZWave_SWITCH_MULTILEVEL_4_nextAstroTimeEvent 24.02.2023 - 17:23
setstate RaffstoreASC 2023-02-24 09:39:33 ZWave_SWITCH_MULTILEVEL_5_nextAstroTimeEvent 24.02.2023 - 17:23
setstate RaffstoreASC 2023-02-24 09:39:30 room_ZWave ZWave_SWITCH_MULTILEVEL_4,ZWave_SWITCH_MULTILEVEL_5
setstate RaffstoreASC 2023-02-24 09:39:33 state created new drive timer
setstate RaffstoreASC 2023-02-24 09:39:30 userAttrList rolled out



Wie nun weiter? Ich sehe nun "Next DriveUp" und "Next DriveUp" ohne das eigentlich gewollt zu haben... Ist das das Einzige, was nun auf einmal automatisch passieren wird? (habe ascEnable sicherheitshalber nochmal auf "off" gesetzt.