MQTT & NEO siren

Configuration
1

I have a Neo siren which is connected and recognised by MQTT. In Devices, the relevant part of theconfig looks like this. You set the config and then turn the device on to hear the sound.

As far as I’ve tested, the UI behaves correctly when using this device and honours your settings. The template which it publishes to set the config looks like this (captured by Listening to the topic)

{“alarm”:false,“battery_low”:null,“battpercentage”:100,“duration”:null,“linkquality”:153,“melody”:2,“volume”:“low”}

So I am trying to create some automations using this device, with different configs depending on the trigger. I was struggling for hours with this, trying to change elecments individually and also with loops and pauses, as have been suggested elsewhere.

Eventually I decided I should just copy the generated template from Listen, which I did.

When you run that element of the autmaiotn you can see in Developer Tools that the values have been changed correctly.

However when you turn on the device (to make the sound) the values all revert back to however the UI is set and my config is ignored. Publishing the package manually makes no difference.

The published packets look identical so it must be something in the device turn-on which is reverting the settings. (Not surprisingly) the device turn-on doesn’t appear in the messages to the topic – only resending the (wrong) config does.

Any ideas please? I can see there have been a number of similar queries but so far none of them have been useful.

2

Well just in case anyone is reading this, I split the config into separate publish statements for each element. That was better and I can now trigger it without it reverting to default.

It was still unreliable at actually making any noise when turned on by an automation. So I dispensed with all the delays that have been suggested and simply looped the action to turn it on 40 times.

It works at least 95% of the time now, which is a huge improvement. I reckon it’s the device simply ignoring commands for no good reason rather than an MQTT problem.