IKEA Vallhorn quirk

[vinzent]

Proposed change

Allows to configure the "on only when dark" and the "on time"
value. Both "only when dark" (on/off) and "on time" (only 60s or 300s) can also be
configured by buttons on the device itself.

There is another attribute 0x0004 in this cluster which I haven't figured out what
it does.

Additional information

Looks like this in my 2025.01.0 HomeAssistant:

Checklist

• The changes are tested and work correctly
• pre-commit checks pass / the code has been formatted using Black
• Tests have been added to verify that the new code works

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.86%. Comparing base (e3d3849) to head (4bd9ace).

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #3681      +/-   ##
==========================================
+ Coverage   89.85%   89.86%   +0.01%     
==========================================
  Files         322      323       +1     
  Lines       10380    10393      +13     
==========================================
+ Hits         9327     9340      +13     
  Misses       1053     1053              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[vinzent]

zha-toolkit device scan: https://gist.github.com/vinzent/af5956db77a20c94556030e812b2211b#file-ikea-vallhorn-zha-tookit-device-scan-json

[vinzent]

I'm unsure if "dark threshold" is really working. Need to check again.

[vinzent]

the 0x0004 attribute might be the reporting interval of the illuminace value. defaults to 60s. the illuminance value seems to be reported on every change of value tough - so I dont know what the benefit is.

[MattWestb]

Its depends of how you is using the data from the sensor.
I using one in the bedroom window and in the summer its closing the blinds then the sun is high enough for heating it up up,
Fast = good and setting one time in HA automation for some minutes so not getting "jo-jo" effect.
Too fast = eating batteries and spamming the logs for no use,
Normally it also possible setting one value limit for updating so not sending every litle change,

Was looking in the ZCL and attribute 0x0004 on cluster type 0x0400 is not reporting its LightSensorType.

7709 4.2.2.2.5 LightSensorType Attribute 
The LightSensorType attribute specifies the electronic type of the light sensor. This attribute shall be set to 
one of the non-reserved values listed in Table 4-6.
Table 4-6. Values of the LightSensorType Attribute
Attribute Value Description
0x00 Photodiode
0x01 CMOS
0x40 – 0xfe Reserved for manufacturer specific light sensor types
0xff Unknown

If reporting is configuball it shall using the normal Zigbee standard for doing it then its one IKEA device = normally very standard.

[MattWestb]

He he eh !!
And the next paragraph was:

7717 4.2.2.5 Attribute Reporting
 This cluster shall support attribute reporting using the Report Attributes command and according to the min�7719 imum and maximum reporting intervals and reportable change settings described in the ZCL Foundation 
 specification (see 2.4.7). The following attributes shall be reported:
 MeasuredValue

So normal reporting setting of the attribute 0x0000 MeasuredValue uint16 0x0000 to 0xffff RP 0x0000 M

[MattWestb]

If you like have the latest ZCL (Zigbee Cluster Library Specification R8) you can getting it here https://csa-iot.org/developer-resource/specifications-download-request/ only need putting in one valid email address.
But for some new IKEA devices it can being they is using upcoming ZCL R9 commands on private cluster but with the matter ZCL (Matter 1.4 Application Cluster Specification) like Symfonisk 2 and sommring is doing.

By the way great work done !!!!!!

[vinzent]

Its depends of how you is using the data from the sensor. I using one in the bedroom window and in the summer its closing the blinds then the sun is high enough for heating it up up, Fast = good and setting one time in HA automation for some minutes so not getting "jo-jo" effect. Too fast = eating batteries and spamming the logs for no use, Normally it also possible setting one value limit for updating so not sending every litle change,

Regardless if I set the cluster 0xFC81 attribute 0x0004 to 300 or anything else, changes of illumination values are reported immediatly (e.g. if I turn on the light in the dark (by HA, not motion), the change is reported immediately). It seems tough without change, the value is reported only every 300 seconds if I configure 300. but its not reflected on export of the history if the value doesn't change but if I hover the mouse in the graph i can see that there seems to be a data point. Maybe i'd need to enable ZHA debug to verify this.

Was looking in the ZCL and attribute 0x0004 on cluster type 0x0400 is not reporting its LightSensorType.

Actually, the IKEA Vallhorn reports this:

which is defined here: https://github.com/zigpy/zigpy/blob/dev/zigpy/zcl/clusters/measurement.py#L13 and matches the zha-toolkit scan: https://gist.github.com/vinzent/af5956db77a20c94556030e812b2211b#file-ikea-vallhorn-zha-tookit-device-scan-json-L1714-L1724

[MattWestb]

Was moving one Vallhorn from Dirigera to test setup and installed your quirk and its looks working very well !!!
If setting the time to 10 and sniffing the network wireschark is showing the frame sent:

ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x01)
    Sequence Number: 40
    Command: On with timed off (0x42)
    Payload
        On/Off Control Mask: 0x00
        On Time: 10.0 seconds
        Off Wait Time: 0.0 seconds

So indeed its possible setting how long time lights shall staying on and that is GREAT !!!
If putting in less then 10 the device is complaining but that is OK then its not user lighting one light for under 10 seconds then somthing is moving.
Do you knowing the max time the device is accepting ?

[MattWestb]

I think 10 is the device lowest so if its possible limiting it here users is not getting errors that they dont understand.
I have not testing the max but if we is getting it i think it shall also being in ZHAs GUI.

[vinzent]

I just used min/max of uint16 here because if I don't specify anything, the slider is 1-100. I can adjust it to 10. will also try to test it myself.

probably the on_time should not be lower than the pir_o_to_u_delay which seems to be 20s.

also in the ZCL specs R8 I found the On/Off cluster provides the on_time attribute, which isn't used by vallhorn:

I also learned that the On/off cluster attribute on_off is mapped to "Opening" in HA/ZHA, which at least for me, a bit confusing word for this.

[MattWestb]

Servus Thomas.
Its depends on with endpoint type the On/Off is on how ZHA is using it if its one type light its making one light and if its one type outlet its make on out let of it and so on plus if its one in or out cluster.
I was using 10 seconds and its looks like the PIR can being triggered OK but i dont knowing if its so exact (perhaps sleeping little more or less some time) but i think its OK having it limited to 10 and if its stable at 20 its up to the user then its only plus functionality in the device.

PS: if you having on extra EZSP coordinator you can using it for sniffing the network and see what its being sent to and from the device and its great for finding strange things devices is doing.

PPS: I have putting my 2 Philips HUE motion sensors in the black box of bad Zigbee devices and im very happy with that !!!!!