[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

[Darkwing Duck]

Danke für den Hinweis, tatsächlich habe ich gestern schon darüber gegrübelt, ob es nicht sinnvoller wäre, das state-Reading schon irgendwann "vorher" zu bekommen. Ich versuche mich heute Abend mal daran und komme auf das Angebot ggf. gern zurück 

[CoolTux]

@CoolTux: Eventuell wäre es insgesamt eine Idee, auch hier DEVICE[:READING] zu ermöglichen (geht jedenfalls lt. cref nicht), so wie beim ASC_windSensor? Der Sensor hier ist sicher nicht der erste oder letzte, der uns "quer" kommt...

Ich denke auch das wir hier eine Erweiterung in Erwägung ziehen sollten. Dann aber wohl komplett

DEVICE:READING OPEN:CLOSED [TITLED]

[Beta-User]

Hmm, weiß nicht recht. An sich ist das sicher richtig, das auch gleich mit angeben zu können. Bleibt aber offen,
- wie die Rückwärtskompabilität/des Verhältnisses zu dem anderen Attribut (und dem, was man evtl. aus dem TYPE und subtype ableiten könnte) sein soll. two/threestate hat ja Auswirkungen auf Teile der Logik;
- was optional ist und was Pflicht. So scheint mir zu viel Pflicht zu sein, bei den CUL_HM-Drehgriffen genügt m.E. eigentlich die Angabe des Namens, den Rest könnte man wissen (bzw. im Modul hinterlegen)...

[CoolTux]

Hmm, weiß nicht recht. An sich ist das sicher richtig, das auch gleich mit angeben zu können. Bleibt aber offen,
- wie die Rückwärtskompabilität/des Verhältnisses zu dem anderen Attribut (und dem, was man evtl. aus dem TYPE und subtype ableiten könnte) sein soll. two/threestate hat ja Auswirkungen auf Teile der Logik;
- was optional ist und was Pflicht. So scheint mir zu viel Pflicht zu sein, bei den CUL_HM-Drehgriffen genügt m.E. eigentlich die Angabe des Namens, den Rest könnte man wissen (bzw. im Modul hinterlegen)...

Können uns ja auch ran testen. Erstmal nur Reading noch mit angeben lassen und dann schauen wir einmal.

[D3ltorohd]

Hm ich hab nur grob mitverfolgt. Ich nutze selber auch Aqara Sensoren für die Fenster mit z2m und hatte hier keinerlei Probleme, diese in ASC ein zu binden.

Noch mal Thema Nachtfahrt Zeit, ich hab ja jetzt Civil, das ist leider zu früh. Was wäre denn das nächste ? Oder sollte ich vllt auf Horizon umstellen und dann zusätzlich mit AutoAstroModeEvening Horizon herumspielen ?

[CoolTux]

Probiere mal. Man sieht ja dann die Zeiten im Reading und kann schauen ob es passt.

[Darkwing Duck]

Hm ich hab nur grob mitverfolgt. Ich nutze selber auch Aqara Sensoren für die Fenster mit z2m und hatte hier keinerlei Probleme, diese in ASC ein zu binden.

Könntest du mir mal ein List eines Fenstersensors posten, damit ich vergleichen kann, wo sich bei mir ggf. etwas unterscheidet?

[D3ltorohd]

Gerne, hier mal ein list vom Sensor.

Code Auswählen Erweitern



Internals:
   DEF        MCCGQ11LM 0x00158d000346ad0c Bad_Sensor
   FRIENDLYNAME Bad_Sensor
   FUUID      5d26118f-f33f-fc62-1620-c5451a8c31eb70f9
   IODev      mqtt
   MODEL      MCCGQ11LM
   NAME       Bad_Sensor
   NOTIFYDEV  MCCGQ11LM 0x00158d000346ad0c Bad_Sensor
   NR         49
   SID        0x00158d000346ad0c
   STATE      close
   TYPE       XiaomiMQTTDevice
   READINGS:
     2019-11-06 20:39:01   battery         ok
     2019-11-06 20:39:01   battery_level   100
     2019-11-06 20:39:01   contact         true
     2019-11-06 20:39:01   device-datecode 20161128
     2019-11-06 20:39:01   device-friendlyname Bad_Sensor
     2019-11-06 20:39:01   device-hwversion 2
     2019-11-06 20:39:01   device-ieeeaddr 0x00158d000346ad0c
     2019-11-06 20:39:01   device-manufid  4151
     2019-11-06 20:39:01   device-manufname LUMI
     2019-11-06 20:39:01   device-modelid  lumi.sensor_magnet.aq2
     2019-11-06 20:39:01   device-nwkaddr  45152
     2019-11-06 20:39:01   device-powersource Battery
     2019-11-06 20:39:01   device-status   online
     2019-11-06 20:39:01   device-swbuildid 3000-0001
     2019-11-06 20:39:01   device-type     EndDevice
     2019-11-06 20:39:01   linkquality     52
     2019-11-03 12:19:14   state           close
     2019-11-06 20:39:01   transmission-state incoming publish received
     2019-11-06 20:39:01   voltage         3005
   message_ids:
   subscribe:
     zigbee2mqtt/Bad_Sensor
     xiaomi/0x00158d000346ad0c/#
   subscribeExpr:
     ^zigbee2mqtt\/Bad_Sensor$
     ^xiaomi\/0x00158d000346ad0c.*$
   subscribeQos:
     xiaomi/0x00158d000346ad0c/# 0
     zigbee2mqtt/Bad_Sensor 0
Attributes:
   IODev      mqtt
   devStateIcon open:fts_window_1w_open@red close:fts_window_1w@green
   room       Xiaomi

Den hab ich dann einfach so eingetragen und fertig.

Code Auswählen Erweitern

ASC_WindowRec Bad_Sensor

[Darkwing Duck]

Danke, damit sehe ich schon den ersten deutlichen Unterschied: Ich habe den Sensor als MQTT2_DEVICE eingebunden und nutze für Zigbee2MQTT den MQTT2_SERVER von FHEM. Ich nehme mal an, darauf wollte Beta-User mit der Anmerkung bzgl. der Templates auch hinaus. Mein Fenstersensor sieht nach meinen gestrigen Experimenten mit $JSONMAP jetzt so aus:

Code Auswählen Erweitern

Internals:
   CID        zigbee_0x00158d00033aa375
   DEF        zigbee_0x00158d00033aa375
   DEVICETOPIC FensterChrisRechts
   FUUID      5d380f2b-f33f-7996-c04f-00862615f933c3c8
   IODev      MQTT2_Server
   LASTInputDev MQTT2_Server
   MQTT2_Server_MSGCNT 27
   MQTT2_Server_TIME 2019-11-07 09:46:50
   MSGCNT     27
   NAME       FensterChrisRechts
   NR         230
   STATE      open
   TYPE       MQTT2_DEVICE
   JSONMAP:
     contact    state
   OLDREADINGS:
   READINGS:
     2019-07-24 09:56:27   associatedWith  MQTT2_mqttjs_0bffb706
     2019-11-07 09:46:50   battery         100
     2019-11-07 09:46:50   linkquality     89
     2019-11-07 09:46:50   state           false
     2019-11-07 09:46:50   voltage         3015
Attributes:
   IODev      MQTT2_Server
   alias      Chris rechts
   devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green
   event-on-change-reading state
   eventMap   true:closed false:open
   group      Fenster
   icon       fts_window_1w_open
   imageLink  /fhem/deviceimages/mqtt2/MCCGQ11LM.jpg
   jsonMap    contact:state
   model      L_06_zigbee2mqtt_ContactSensor
   readingList zigbee2mqtt/0x00158d00033aa375:.* { json2nameValue($EVENT, '', $JSONMAP) }
   room       Chris,Devicetypes->MQTT,MQTT2_DEVICE,Überblick

Damit habe ich jetzt zumindest ein Reading mit dem Namen "state" erzeugt. Hier komme ich jetzt allerdings nicht so recht weiter. Unklar ist mir:

• Wieso hat die eventMap keine Auswirkungen auf den Zustand des Readings "state"? Habe ich das missverstanden? Oder wie bekomme ich hier anderweitig open und closed statt false und true hinein?
• Was fehlt noch, damit ASC in irgendeiner Form reagiert? Egal, ob ich wie oben aufgeführt event-on-change-reading explizit setze oder nicht, das "EventProcessingWindowRec" erscheint nicht im ASC-Debug-Log.

Für etwas Hilfestellung wäre ich an dieser Stelle sehr dankbar 

Und der Vollständigkeit halber hier noch die zugehörige Jalousie:

Code Auswählen Erweitern

Internals:
   ADDRESS    2711EE
   DEF        2711EE A1 0201
   FUUID      5d088e82-f33f-7996-c547-856507c93f1c8725
   IODev      sduino
   NAME       JalousieChrisRechts
   NR         176
   STATE      open
   TYPE       SOMFY
   move       stop
   CODE:
     1          2711EE
   OLDREADINGS:
   READINGS:
     2019-07-01 11:39:47   ASC_Enable      on
     2019-11-07 09:27:25   ASC_ShuttersLastDrive manual
     2019-11-07 08:00:15   ASC_Time_DriveDown  7.11.2019 - 17:19
     2019-11-07 08:00:15   ASC_Time_DriveUp  8.11.2019 - 08:00
     2019-11-06 19:21:26   associatedWith  asc
     2019-11-07 09:27:06   enc_key         A1
     2019-11-07 09:27:25   exact           0
     2019-11-07 09:27:25   position        0
     2019-11-07 09:27:06   rolling_code    0201
     2019-11-07 09:27:25   state           open
Attributes:
   ASC        1
   ASC_Drive_OffsetStart 5
   ASC_Pos_Reading position
   ASC_Time_Down_Late 22:30
   ASC_Time_Up_Early 08:00
   ASC_Ventilate_Pos 30
   ASC_Ventilate_Window_Open on
   ASC_WindowRec FensterChrisRechts
   ASC_WindowRec_subType twostate
   IODev      sduino
   alias      Chris rechts
   devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 100:fts_shutter_100 down:fts_shutter_100 closed:fts_shutter_100
   drive-down-time-to-100 22
   drive-down-time-to-close 26
   drive-up-time-to-100 4
   drive-up-time-to-open 27
   eventMap   /on:close/pos 100:down/stop:stop/off:up/
   group      Jalousien
   icon       fts_shutter
   model      somfyshutter
   room       Chris,SOMFY,Überblick
   userattr   ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Offset ASC_Drive_OffsetStart ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownTime_beforNightClose ASC_PrivacyDown_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Exclude:on,off ASC_Self_Defense_Mode:absent,gone ASC_Shading_Angle_Left ASC_Shading_Angle_Right ASC_Shading_Direction ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate
   webCmd     close:down:stop:up

[CoolTux]

Am besten Du entfernst erstmal den Fensterkontakt aus dem Rollo. Ich gehe davon aus das mittlerweile zu viel durcheinander gekommen ist.
Dann sorgst Du mit Hilfe von Helfern dafür das Dein Fensterkontakt im state ein open oder closed schreibst und fügst dann den Fensterkontakt wieder zur Rollokonfig hinzu.

[Darkwing Duck]

"Helfer" heißt in diesem Zusammenhang so etwas wie ein Notify, das ein "setreading JalousieDevice state open" auslöst? Dann versuche ich das heute Abend mal an einem anderen Fensterkontakt, der bisher noch nicht mit ASC benutzt wurde.

[CoolTux]

"Helfer" heißt in diesem Zusammenhang so etwas wie ein Notify, das ein "setreading JalousieDevice state open" auslöst? Dann versuche ich das heute Abend mal an einem anderen Fensterkontakt, der bisher noch nicht mit ASC benutzt wurde.

Nein ich meine User die Dir helfen können Dein MQTT entsprechend ein zu richten. 

[Beta-User]

Hmm, das mit JSONMAP paßt soweit, aber "eventMap" greift "nach" dem "state"-Reading ein und verändert nur Events und das Internal STATE. Wenn wir wirklich den Reading-Inhalt "open" oder "closed" benötigen, dann müßten wir wirklich mit einem userReading arbeiten (und könnten auf JSONMAP, eventMap und stateFormat verzichten). Aber eigentlich finde ich das eher suboptimal, da (aus der Hüfte) auch andere Device-TYPEs boolsche Readinginhalte erzeugen (MYSENSORS_DEVICE, z.B.). Da bin ich mir aber nicht sicher, ob da die Logik nicht grade verdreht ist (also "open"="true")...

@CoolTux: Kurz hatte ich überlegt, ob es für den generischen Abgleich (ohne die an anderer Stelle jüngst bei V 0.8 diskutierte Attribut-Option) nicht sinnvoll wäre, die boolschen Werte nicht in die Prüfung einzubauen (ist das eine Regex, dann sollte das kein größeres Problem sein?)?

Für den Moment würde ich das von JSONMAP zurückdrehen und ein userReadings-Attribut nutzen. Ungetestet:

Code Auswählen Erweitern

attr DEVICE userReadings state:contact.(true|false).* {ReadingsVal($name,"contact","false") eq "false" ? "open" : "closed"}

[CoolTux]

Es ist RegEx. Eine Anpassung wäre also möglich. Ich befürchte nur das dann die nächsten kommen mit anderen Werten und auch eine Anpassung wünschen.
Und wie genau soll die Anpassung anschauen?

[Beta-User]

  Die Befürchtung teile ich, da kommt bestimmt bald der nächste und findet das falsch rum usw....

Aber mit einem gewissen Restrisiko würde ich behaupten, dass "true" als "geschlossen" (und false=open) zu werten i.O. wäre.
Zum Hintergrund: nach meinem Eindruck hält sich zigbee2mqtt sehr eng an den OpenHAB-Standard, der wiederum von vielen anderen MQTT-Implementierungen als defacto-Standard akzeptiert wird...
(Für MYSENSORS_DEVICE kann man dann immer noch das userReadings-Mapping machen bzw. die kommende Implementierung abwarten). Ist halt wie oft 80:20...