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.

[arteck]

this object 'execute_warning' is generated from us.. https://github.com/ioBroker/ioBroker.zigbee/blob/59dede6d49c46ef88d7e9bd487ceefe064d355fa/lib/states.js#L837 this exists not in converter.

[kptkip]

When I follow the logic that bitron_execute_warning ist triggering the siren (Hope, I am right) and see this from devices.js:

models: ['902010/24'],
        icon: 'img/bitron_902010_24.png',
        states: [states.heiman_batt_low, states.smoke_detected, states.bitron_execute_warning],
    },
    {
        models: ['902010/29'],
        icon: 'img/bitron_902010_29.png',
        states: [states.heiman_batt_low, states.bitron_execute_warning],
    },
    {
        models: ['AV2010/24A'],
        icon: 'img/bitron_AV2010_24A.png',
        states: [states.heiman_batt_low, states.smoke_detected, states.bitron_execute_warning],

I wonder, why a) the data points of the devices are different b) the execute command works with 2010/24A and with 2010/24 not

[asgothian]

As @galegro tested, the general function of the units using the send_payload system is given. The issue with the device not responding (send command failed with no error code) is not connected to the adapter software but to your network parameters, and an indication that the zigbee communication does not work properly.

There will be no return to the bitron_execute_warning state, as this is moving backwards into non-standard implementation.

[galegro]

Here you will find my procedure for the smoke detector type 902010/24.

The "strobe" parameter must be present and must be set to "false". The remaining parameters for the strobe option can/should be omitted at this time, as they have no effect.

The outdoor siren 902010/29 contains an acoustic and optical alarm device. I will test whether the strobe parameters show effects with this siren.

[kptkip]

Do I understand you right to try putting

{'strobe':false, 'duration':x} -- with x=NUMBER OF SECONDS

into the data point "send_payload" from a 902010/24 device?

[galegro]

{'strobe':false, 'duration':x} -- with x=NUMBER OF SECONDS

into the data point "send_payload" from a 902010/24 device?

See Here! This works without any problems.

[kptkip]

this was the source I was quoting...

[galegro]

Just try! ;-)

[kptkip]

Already tried - obviously: No effect. Still the same.

BTW: Since 1st of April Here I can't find a single post that brings me to the opinion that it would "work without any problems" for anybody. I have problems to understand how you come to this conclusion?!

[galegro]

Already tried - obviously: No effect. Still the same.

Let's discuss the whole thing here!

[galegro]

.. I can't find a single post that brings me to the opinion that it would "work without any problems" for anybody. I have problems to understand how you come to this conclusion?!

Of course there are still problems. But there is already enough to set up an alarm system.

Try the example I gave here!

[galegro]

.. I have problems to understand how you come to this conclusion?!

In the meantime I can understand your objections. If I send several commands to the siren, over time it gets completely confused and reacts incorrectly or not at all.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[arteck]

work it now or not ? new version 1.8.16

[kptkip]

With this command {"warning":{"strobe":false, "duration":0}} into send_command data point the siren starts.

With {"warning": {"mode": "stop"}} it stops.

[Ilovegym66]

Oh Great!! With this command I can start the sirene manually of the SMB-Z120 from FRIENT/DEVOLCO.. {"warning":{"strobe":false, "duration":60}} Duration must be set for the duration time, with 0 it's a earlier stop possible. Thanks, now I've a workaround ..