@AlexTrovato
In the « Zigbee Discovery » screen, I have an error message that I can’t delete.
This is about registering my siren, the second feature (Siren) is missing, hence the registration error.
I restored old backups with no result, I also restored an old database, same thing.
Is there a solution?
Hello, what Zigbee device are you trying to integrate?
I can already see there is a display issue.
@AlexTrovato
In fact, it’s all my fault, I made a mistake (when you don’t know, you don’t touch!) but I touched it anyway!
After updating the binaryType.js file with the siren code:
alarm: {
feature: {
category: DEVICE_FEATURE_CATEGORIES.SIREN,
type: DEVICE_FEATURE_TYPES.SIREN.BINARY,
},
},
it was correctly recognized in Gladys. However, the On/Off command did not work. I checked that it worked with the 8080 web interface, which was the case.
I then tried to replace SIREN with SWITCH, but I may have made a typo, which is why only one feature (the battery one) is left.
I’m stuck now, as I can’t get my siren recognized anymore.
Thanks for your help.
So, in conclusion, there is no problem?
@AlexTrovato
edit:
My siren is correctly recognized by Gladys with two of its features: « Battery » and « Siren ON/OFF » as can be seen in the screenshot above.
However, I cannot control it, neither directly from the dashboard nor in a scene with a trigger.
I confirm that the siren works well, by the way, since I can control it via the zigbee2mqtt interface on port 8080.
Thank you for your enlightened opinion.
I think this is related to this PR
If you have a chance to check it out 
Thanks @AlexTrovato
I tried both versions of the code:
zigbeeValue = value ? ON:OFF;
or
zigbeeValue = value ? {\"state\": \"ON\"} : {\"state\": \"OFF\"};
and I get the same error message in the z2m:8080 interface when I command the siren from Gladys:
However, if I command the siren from the z2m interface, the siren works, Gladys receives the command and I get the confirmation log:
If you want me to look at anything else, within the limits of my skills, I am at your disposal.
Have a good evening.
@AlexTrovato Excuse me for coming back to you about my Tuya siren integration issue.
Do you think there might be a long-term solution, or should I give up? I wanted to use it for a home alarm, so I really hoped it would work. It is recognized by Gladys by updating the binaryType.js file, but the ON/OFF exposure does not respond.
Thank you.
If I read correctly, it’s ‹ true › and ‹ false › that you need to send (generally, 1 and 0 are equivalent)
And even ‹ alarm › 1
That’s right, it’s a binary message (True or False)
Sorry I didn’t have time to look but no we are not giving up. Don’t hesitate to remind me as I don’t often have time available, so I forget.
Yes, I requested to add these true/false values. I had the same issue controlling my IPX800V5, which expects true/false values. I worked around it using Node-RED!
Hello, I just proposed a specific value management.
See here: https://github.com/GladysAssistant/Gladys/pull/1383/commits/05332506707169b7969583681071894d41374ad6
You will need to re-add/update the device.
What I did:
When discovering a Zigbee device, it provides the values it expects for ON/OFF.
I therefore keep this ON/OFF mapping in a device attribute and use it when reading/writing the value.
Why:
Each device can handle different values, and zigbee2mqtt does not perform this conversion by default, so we have to do it.
For the TS0216 alarm, the device expects « true/false », by default it’s « ON/OFF », for others, I have even seen « START/STOP », while they are all binary devices.
@pierre-gilles I leave it to you to confirm that this operation is not disturbing in the Gladys vision.
We could have had information at the feature level rather than on the device, but the current model does not allow that.
@AlexTrovato Thanks Alex, I know you’re putting in a lot of effort, so no problem, the main thing is to get there, so take your time according to your availability.
Unfortunately, I will be absent for a week, so I won’t be able to test your PR right away.
Stay tuned!
Since this is information provided by Zigbee2mqtt in the JSON, it doesn’t surprise me to store it in the params 
Otherwise, if it was a manual thing, I would have stored it in the code, but indeed, if it’s automatic, the params are very good.
For a more detailed review of the PR, I would appreciate a review from someone who has also worked on this service, @cicoub13 for example 
Hello @jparbel
What is the reference of your Tuya siren?
How did you integrate it into Gladys?
Do you need the Tuya gateway?
I modified it to no longer store the information because when Gladys connects to the MQTT of Zigbee, it retrieves the devices in the z2m format and stores them.
So I reuse them, do the reverse mapping, to send the right message.
So it stays in RAM, and we are sure to have the latest fresh information, in case the z2m devices evolve.
@jparbel is trying to test the generated image atrovato/gladys:zigbee2mqtt
EDIT: Call to other motivated people to also test this new image (whether to test compatibility on new devices, or non-regression on those that already work), thank you all
Is it based on the gladys dev or the prod?
Because I’m testing the dev right now, to see if I can continue both in parallel!
It is based on the dev image, so with the latest upgrades.