Alarm siren doesn't work anymore

[kptkip]

Since several versions of the adapter the sirens in my smoke detectors AV2010/24 are not possible to activate. With my outdoor siren AV2010/29 it is the same issue.

Only the smoke detectors AV2010/24A still work.

In between the first ones and the latter the entire structure of data points as changed.

Has anyone ideas how to reactivate the alarm feature?

Thanks a lot!

Here are some screenshots of the interface and the data points structure:

[kptkip]

After deleting an re-installing the smoke detector I get the following message in the protocol from the adapter: WOW!

zigbee.0 | 2022-03-20 15:57:00.321 | warn | This object will not be created in future versions. Please report this to the developer.
-- | -- | -- | --
zigbee.0 | 2022-03-20 15:57:00.320 | warn | Object 00124b0008e67d8e.mode is invalid: obj.common.states has an invalid type! Expected "object", received "string"
zigbee.0 | 2022-03-20 15:57:00.254 | warn | Device '0x00124b0008e67d8e' announced itself

[asgothian]

• Which adapter version are you using ?
• is the smoke detector listed as "to exclude" (ausschliessen) in the adapter ? If not, please add it to the excluded devices. A.

[kptkip]

Currently I am using 1.6.16 - in version 1.6.0 it worked perfectly. I've put on the "to exclude" list - no effect until now.

[asgothian]

• did you restart the adapter after adding the device to the exclude list ?
• did you perform a state cleanup after restarting ?

[kptkip]

I restarted the adapter several times. I also deleted the device and re-paired it again. No Changes. Also state cleanup didn't work.

[kptkip]

There is one thing, I can't understand:

The AV2010/24 and the AV2010/24A are identical devices -biside of the type name.

Even the explanation in Zigbee2MQTT is identical and the config in devices.js in this package is also identical.

Why is the device appearing in the adapter GUI in a complete different manner with different data points?

Greetings Alex

[arteck]

set the duration to 5 .. same reaction ?

[kptkip]

It is always the same issue - no reaction. I've tried a vast amount of values

It is obvious: We are discussing more about symptoms and workarounds with time-consuming trial & error.

The root-cause lies in the question: For what reason has the implementation of 902010/24 and 902010/29 changed since 1.6.0? The data point structure changed for no clear reason and the reflecting GUI of theses devices in the adapter-overview also (s screenshots here https://github.com/ioBroker/ioBroker.zigbee/issues/1397#issue-1174297803). In MQTT2Zigbee nothing changed. Since this change the devices are no more capable to activate the siren.

While we start thinking in the direction DIFF between AV2010/24 and AV2010/24A we will come closer to a solution.

[arteck]

For what reason has the implementation of 902010/24 and 902010/29 changed since 1.6.0?

no changes here our site.. check GIT for this device when it is to slow for you.. or our questions are too tedious to answer for you..

check the code.. fix the bug.. make a PR.. and you are lucky... so simple is it

so far I do not see the bug.. in source

[asgothian]

Your screenshot does not match the definition given by the exposes for the devices on zigbee2mqtt.io.

Please ensure

• that both devices are active in the exposes

• that you run the adapter internal state cleanup (with the force clean set) after restarting the adapter ( )

• that both devices show the following states:

• smoke,battery_low,tamper,mode,level,strobe_level,strobe_duty_cycle,duration,link_quality,message_from_zigbee,available,device_query,send_payload

• Install the fork of the adapter from my repository (https://github.com/asgothian/ioBroker.zigbee)

The initial attempt to set the alarm would be to change the mode state to emergency after setting the duration to 60

The next attempt is to put the following text into the send_payload state:

{"warning": {"mode": "stop","level": "low","strobe_level": "low","strobe": false,"strobe_duty_cycle": 10,"duration": 10}}

[kptkip]

@asgothian OK, I tried my best to find & ensure all theses points:

Your screenshot does not match the definition given by the exposes for the devices on zigbee2mqtt.io.

Sorry, I don't understand, what this means. But my observation is: These kind of devices work all properly: The devices with this kind of view not:

Please ensure

• that both devices are active in the exposes

Sorry, I don't understand, what this means. Do you mean this - if yes, they are all active:

• that you run the adapter internal state cleanup (with the force clean set) after restarting the adapter (

Did this several times - no effect:

• that both devices show the following states: smoke,battery_low,tamper,mode,level,strobe_level,strobe_duty_cycle,duration,link_quality,message_from_zigbee,available,device_query,send_payload

The latter doesn't exist - neither in the data point structure of 902010/24 nor in 902010/24A:

• Install the fork of the adapter from my repository (https://github.com/asgothian/ioBroker.zigbee)

I'll gonna check this out later after backing up everything.

The initial attempt to set the alarm would be to change the mode state to emergency after setting the duration to 60

Tried this - no success (1. duration 60sek 2. mode to emergency). (see screenshot above)

The next attempt is to put the following text into the send_payload state:

{"warning": {"mode": "stop","level": "low","strobe_level": "low","strobe": false,"strobe_duty_cycle": 10,"duration": 10}}

Where can I do this - the data point "send_payload" doesn't exist as you can see above. Eventually somewhere here?

[kptkip]

Should we combine/link these threads https://github.com/ioBroker/ioBroker.zigbee/issues/766#issuecomment-1073880750 ? There is the same discussion going on - unfortunately only in german.

[galegro]

Here my tests and experiencies.

Obviously the current states "execute_warnings" in the objects 902010/24 etc are available not anymore

[asgothian]

Should we combine/link these threads #766 (comment) ? There is the same discussion going on - unfortunately only in german.

No. 766 has been closed after the initial implementation of the siren.

[asgothian]

The State "send_payload" will be available once you installed from my GitHub branch.

A.

[galegro]

The State "send_payload" will be available once you installed from my GitHub branch.

In this case, do I use „send_payload“ instead of „execute_warnings“?

Where can I find your branch?

[kptkip]

OK, here is the update:

• Install the fork of the adapter from my repository (https://github.com/asgothian/ioBroker.zigbee)

I installed this version successfully. :-)

Now there are the data points "zigbee.0.[DEVICEID].send_payload".

But none of the given hints worked for me - neither putting the JSON part into send_payload nor playing around with the duration length or mode. :-(

[asgothian]

please post the log results from when you entered the data.

[kptkip]

Here you can find the error result for several attempts with 2 devices (902010/24 902010/29):

zigbee.0 | 2022-03-21 21:49:49.253 | error | Send command to 0x00124b0008e757b9 failed with no error code (Timeout - 64365 - 1 - 86 - 1282 - 11 after 10000ms)
zigbee.0 | 2022-03-21 21:49:43.577 | error | Send command to 0x00124b0008d8dba4 failed with no error code (Timeout - 24981 - 1 - 88 - 1282 - 11 after 10000ms)
zigbee.0 | 2022-03-21 21:49:26.206 | error | Send command to 0x00124b0008e757b9 failed with no error code (Timeout - 64365 - 1 - 85 - 1282 - 11 after 10000ms)

[asgothian]

This is an indication that the siren does not respond.

• Do you get status updates from the siren at all ?
• Do you get similar messages when the you attempt the test i referenced above ?

A.

[kptkip]

This is an indication that the siren does not respond.

• Do you get status updates from the siren at all ? I get a response from the device in iobroker. I did a reality-check with real smoke to check weather theDevice reacts and give Information about smoke -> perfectly 😎

• Do you get similar messages when the you attempt the test i referenced above ?

Do you think of this one? {"warning": {"mode": "stop","level": "low","strobe_level": "low","strobe": false,"strobe_duty_cycle": 10,"duration": 10}}

[asgothian]

No, i was thinking about the separate states mode, level, duration, etc.

[kptkip]

There is no reaction in the siren.

duration tested: 60s , 1s, 5s,10s,.. mode: emergency, fire, stop, burglar strobe false

The protocol says:

zigbee.0 | 2022-03-23 21:33:05.181 | error | Send command to 0x00124b0008e757b9 failed with no error code (Timeout - 64365 - 1 - 15 - 1282 - 11 after 10000ms)
zigbee.0 | 2022-03-23 21:32:38.768 | error | Send command to 0x00124b0008e757b9 failed with no error code (Timeout - 64365 - 1 - 14 - 1282 - 11 after 10000ms)
zigbee.0 | 2022-03-23 21:32:15.715 | error | Send command to 0x00124b0008e757b9 failed with no error code (Timeout - 64365 - 1 - 13 - 1282 - 11 after 10000ms)

[asgothian]

please remove the device and pair it again - at the location you use it. It seems there is an issue with the communication to the device, on top of the actual integration in ioBroker.

[kptkip]

I've done this several times.

[kptkip]

What I wonder:

The never version of the smoke detector 2010/24A has a datapoint "execute_warning". This is the trigger to start the siren.

This trigger doesn't exist in the list of datapoints not - there are only settings datapoints. Can it be that the trigger itself is not there and for that the siren doesn't start?

[asgothian]

The execute_warning state should no longer be active for any of the sirens with the current zigbee-herdsman-converters as that was changed. No communication seems to work as the messages sent to the device are not confirmed - that is what the timeout message signals.

A.

[kptkip]

The recieving of the smoke status works. Ive tried this yesterday.

So it is only the sending direction?

[kptkip]

If I look on the writeable datapoins in the object structure I observe red (not send/confirmed) values. That fits to the hypothesis that the device doesn't receive the data.

A general question: How many and which components are involved in this adapter? As you mentioned not having changed the adapter itself. It would help thinking which of the involved (especially those from koenkk and maybe others) components have made changes in the last month. So we can come closer to the root-cause.

[asgothian]

The relevant components are the zigbee-herdsman and zigbee-herdsman-converters project. There have been a large number of changes in the zigbee-herdsman-converters project as they have been moving towards a system which is called "exposes" - this system is responsible for the states which are generated for devices we do not specify states for directly or for devices entered into the exclude list. Among these changes was the removal of the 'execute_warning' converter, so the state with the same name we have stopped working.

A.