help needed with extra info on Develco/Frient Sensors like Smoke&Fire detector devices (SMSZB-120& HESZB-120) and Motion

[mamrai1]

query of GenBinaryInput:
Read result of 'genBinaryInput': {"outOfService":0,"presentValue":0,"reliability":0}

datasheet of detectors:

Which one(s) are needed to show if device is working properly and how to create a converter for them?
Also most develco sensors like all motions MOSZB-130-140, window WISZB-120, water leak FLSZB-110 support this feature...
specifically motion sensors support only these:

[Koenkk]

@TheStigh could you check this?

[TheStigh]

@Koenkk @mamrai1

Currently on business travel until Sept 2nd, but I can have a look at test on my Develco devices when I return. Shouldn't be any issue to add these.

[TheStigh]

@mamrai1

Something like this?

Seems outOfService, presentValue and reliability are linked. You also got the statusFlags bit:1 that are fault with true or false. It is not clear to me if we only would need to show the statusFlags. In my example above, I've added all as attributes.

Are this what you wanted ?

[mamrai1]

Yes, that's perfect👌

[TheStigh]

Yes, that's perfect👌

Okie, I'll do the PR of this new converter :)

[mamrai1]

Works ok...
Regarding battery: i think is wrong(screenshot)

[rindlerblabla]

There's another open issue regarding the battery calculation, see Koenkk/zigbee2mqtt#8457.

[mamrai1]

Just show that! Thanks, i have changed battery percentage to 3V_2500 and shows now 80%

[TheStigh]

I can update the PR with the 3V_2500...

[mamrai1]

Perdect i will add the pr for the fire sensor :)

[TheStigh]

Perdect i will add the pr for the fire sensor :)

Pls wait until I've updated the PR with more changes

[TheStigh]

@Koenkk @rindlerblabla @mamrai1

I would like an input from you guys regarding the attributes OutOfService and PresentValue. What would we want to achieve here? I would say to get a the state and status of the physical device (smoke, fire etc). In my opinion, what we would only need are the StatusFlags (will/could result additional 4 new booleans) and the Reliability.

Could you please read below and give me the opinion what I should implement? I can't say I fully understand WHY we should show OutOfService and PresentValue (I've made converters for them both, and even made OutOfService switchable). Are the OutOfService meant to be used by a user if they "do something with the device", like removing it, replacing battery or for some other reason put it out of commission for a short period?

From ZCL:

3.14.11.1 OutOfService Attribute
The OutOfService attribute, of type Boolean, indicates whether (TRUE) or not (FALSE) the physical input,
output or value that the cluster represents is not in service. For an Input cluster, when OutOfService is TRUE
the PresentValue attribute is decoupled from the physical input and will not track changes to the physical
input. For an Output cluster, when OutOfService is TRUE the PresentValue attribute is decoupled from the
physical output, so changes to PresentValue will not affect the physical output. For a Value cluster, when
OutOfService is TRUE the PresentValue attribute MAY be written to freely by software local to the device
that the cluster resides on.

3.14.11.2 PresentValue Attribute
The PresentValue attribute indicates the current value of the input, output or value, as appropriate for the
cluster. For Analog clusters it is of type single precision, for Binary clusters it is of type Boolean, and for
multistate clusters it is of type Unsigned 16-bit integer.
The PresentValue attribute of an input cluster SHALL be writable when OutOfService is TRUE.
When the PriorityArray attribute is implemented, writing to PresentValue SHALL be equivalent to writing
to element 16 of PriorityArray, i.e., with a priority of 16

3.14.11.3 StatusFlags Attribute
This attribute, of type bitmap, represents four Boolean flags that indicate the general “health” of the analog
sensor. Three of the flags are associated with the values of other optional attributes of this cluster. A more
detailed status could be determined by reading the optional attributes (if supported) that are linked to these
flags. The relationship between individual flags is not defined. The four flags are
Bit 0 = IN ALARM, Bit 1 = FAULT, Bit 2 = OVERRIDDEN, Bit 3 = OUT OF SERVICE
where:
IN ALARM - Logical FALSE (0) if the EventState attribute has a value of NORMAL, otherwise logical
TRUE (1). This bit is always 0 unless the cluster implementing the EventState attribute is implemented on the
same endpoint.
FAULT - Logical TRUE (1) if the Reliability attribute is present and does not have a value of NO FAULT
DETECTED, otherwise logical FALSE (0).
OVERRIDDEN - Logical TRUE (1) if the cluster has been overridden by some mechanism local to the
device. Otherwise, the value is logical FALSE (0).
In this context, for an input cluster, “overridden” is taken to mean that the PresentValue and Reliability
(optional) attributes are no longer tracking changes to the physical input. For an Output cluster, “overridden”
is taken to mean that the physical output is no longer tracking changes to the PresentValue attribute and the
Reliability attribute is no longer a reflection of the physical output. For a Value cluster, “overridden” is taken
to mean that the PresentValue attribute is not writeable.
OUT OF SERVICE - Logical TRUE (1) if the OutOfService attribute has a value of TRUE, otherwise logical
FALSE (0)

3.14.11.9 Reliability Attribute
The Reliability attribute, of type 8-bit enumeration, provides an indication of whether the PresentValue or the
operation of the physical input, output or value in question (as appropriate for the cluster) is “reliable” as far
as can be determined and, if not, why not. The Reliability attribute MAY have any of the following values:
NO-FAULT-DETECTED (0)
NO-SENSOR (1) - for input clusters only
OVER-RANGE (2)
UNDER-RANGE (3)
OPEN-LOOP (4)
SHORTED-LOOP (5)
NO-OUTPUT (6) - for input clusters only
UNRELIABLE-OTHER (7)
PROCESS-ERROR (8)
MULTI-STATE-FAULT (9) - for multistate clusters only
CONFIGURATION-ERROR (10)

[mamrai1]

StatusFlags attribute is not supported from Develco motion sensors(as seen from the manual).. Reliability attribute is the only needed one to show if a device is working or not.. As for the outofservice attribute is not clear for me if the firmware changes the value to true if an error occurs

[TheStigh]

StatusFlags attribute is not supported from Develco motion sensors(as seen from the manual).. Reliability attribute is the only needed one to show if a device is working or not.. As for the outofservice attribute is not clear for me if the firmware changes the value to true if an error occurs

@mamrai1

Could you please test the full converter on the motion sensor and then see if the attributes appear?
As I use hasOwnProperty('statusFlags') it should not appear for motion sensor according to your comment.

I think I will remove the outOfService and presentValue. Do you agree?

[mamrai1]

Sorry i don't have a motion sensor to test..
Regarding outofservixe and present value, it's just extra information even if we thing is 'useless'... Why remove it?

[mamrai1]

You can keep it simple and remove outOfService and presentValue...

[TheStigh]

PR already updated. Tested on Develco's Smart Siren - none of the attributes show. Guess we can close this now.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days