zigbee2mqtt error message

Thank you for your response, I am testing the image at the moment.
Do I need to remove/add my equipment or is the update automatic on the mapping?

For the moment I don’t have any regressions, but some mappings don’t work because they are not yet supported in Gladys (connected radiator thermostatic heads):

I discovered that the second button on the dashboard corresponds to « window detection », the first one I still don’t know :sweat_smile: Impossible in Gladys to know what the different buttons correspond to in Zigbee2Mqtt for the moment.

Isn’t the first one eco_mode?

Yes indeed. Gladys is missing the switch corresponding to boost_heating which is not visible in my screenshot.
For now the interface displays the value, but I cannot use the switch because Gladys does not return the values accepted by Zigbee2Mqtt:

@lmilcent Normally, there is no need to delete/add equipment, except to integrate new features that may have been discovered (which is not the purpose of the image).

Do I need to review the default naming of the features?
(I need to check if it’s the naming of the features or the display on the dashboard)

Regarding the LOCK issue, it is identified as fixed in the ticket [Zigbee2Mqtt] Failed to convert value for device RadiateurSalon: Error: Zigbee2mqqt don't handle value "LOCK" for feature "mode". · Issue #1448 · GladysAssistant/Gladys · GitHub.
Do you have the latest image atrovato/gladys:zigbee2mqtt generated last night?

Is the message « No converter available… » identified on the device Moes BRT-100-TRV?
If so, check that the image is correct. In theory, the « state » property is not used on this device, but « child_lock ».

I don’t think there’s a connection but I have this message.

lol ok fine… we’re doing neither LQI, nor Coordinator…

thanks :wink:

Hello,
I saw that there is alarm and CO2 integration in the test image, I already have both devices in a box, can I switch from the official image to the DEV one without breaking everything or is there a risk?

The zero-risk scenario does not exist, but I am rather confident.
A backup of the database beforehand is recommended.

I just tested, the features are well detected for the alarm (Tuya TS0216 control via MQTT | Zigbee2MQTT), a CO detector (Heiman HS1CA-E control via MQTT | Zigbee2MQTT), and a smoke detector (https://www.zigbee2mqtt.io/devices/HS1SA.html).

However, I don’t know if the absence of a value for the detectors is standard or if there should be a 0 or a value set to « No » by default.

(PS by the way, all three devices have a siren and I said goodbye to my hearing for the afternoon :stuck_out_tongue: )

For the default value, I’ve thought about it, that will be a next step. Let’s first validate the even more comprehensive management of devices.

Have you played with the alarms since Gladys? The earplugs weren’t provided?? :stuck_out_tongue:

Yes, I played with the alarm, just in a scene with activation at a specific time, it worked well, and the start/stop button also works well!

Unfortunately not, and I didn’t expect so much noise, especially from the two CO and smoke detectors :smiley:

In any case, great work, it promises great possibilities for the future :wink:

Edit: it would be interesting to be able to manage the volume of the alarm siren in Gladys a bit on the same principle as the brightness of a lamp

I must have a problem with my TS0216 alarm, as I still can’t get it recognized despite numerous attempts.
However, I invested in a Tuya Gateway (Lidl) to check it: it works well from the dedicated interface. I don’t understand what’s going on?

Sorry @AlexTrovato I couldn’t respond earlier. To my knowledge, I did have the latest version of the docker image.

Hmm, I don’t know, how can I check that? For info, it’s me who opened the GitHub issue you mentioned :wink:

Haha now that you mention it, indeed the usernames match :wink:

The last test image is in version 4.8.0 (Gladys → Admin → System).
According to the GitHub ticket, it seems to work, unless you just copied the files, which does not validate the test image.

For information, I have merged the PR from @AlexTrovato which brings the custom mappings to the Zigbee2mqtt integration!

I just launched a DEV build on the Docker tag which will be ready within an hour:

gladysassistant/gladys:dev

(The build: https://github.com/GladysAssistant/Gladys/actions/runs/2078334755)

I am open to feedback on the Zigbee2mqtt integration, to verify that it indeed brings the expected behavior for devices that were not managed before, and that it does not break the rest of Zigbee2mqtt of course :smiley:

Thanks to those who will test it!

@pierre-gilles On which RPI OS can we test this build?

On all (it’s not OS-dependent)

Thanks @VonOx It works correctly for me with my devices: lamps, outlets, siren, temperature, humidity, tested with a CC2652 BLE Simplelink 2.2G Zigbee2MQTT dongle
Thanks and congratulations on a job well done!
For information, my Sonoff dongle recognizes all my devices, it works correctly in reception but not in transmission, has this problem already been reported?

On air?

That is to say in command mode for switches, lamps or a siren