URGENT Getting device properties doesn't work anymore "trust_state"

“fw_ver”:“v2.10.21”,“fw_date”:“Wed Feb 19 15:31:13 UTC 2020”

Execute cmd: /v2/devices/4a28142a/properties/
{"branding_profile":"SOMFY","addr":12998348,"_":"c615e966"} 

“trust_state” is gone?

So much for URGENT :face_with_hand_over_mouth:

Not sure if you’ll get the response you need through regular support, but @merck and others on the Bond team have mentioned to use the Help Desk for time-sensitive support.

For what it’s worth (which is little, granted): I am still showing “trust_state” for all my devices across both Bond Bridges I have (BD and ZZ revisions) - but I do not have any Somfy devices.
Both are on beta firmware, however: fw_ver 2.11.10-beta / Apr 24

EDIT: (copy pasted from posts by the Bond team)
…you can contact our customer support at customersupport@olibra.io , or by opening a support chat in the Bond Home app…

Hi Chris,

Can you please have a look https://forum.bondhome.io/t/urgent-getting-device-properties-doesnt-work-anymore-trust-state/1542



|
URGENT Getting device properties doesn’t work anymore “trust_state”
“fw_ver”:“v2.10.21”,“fw_date”:“Wed Feb 19 15:31:13 UTC 2020” Execute cmd: /v2/devices/4a28142a/properties/ {“branding_profile”:“SOMFY”,“addr”:12998348,“_”:“c615e966”} “trust_state” is gone?
forum.bondhome.io
|

  • | - |

Thank you,

Alex

That’s promising:
image

[EDIT] customerservice@bondhome.io?

Welp, that sucks.
FYI @jacob / @feliperuhland (already @'d Chris above).

(Think they’ve been using @olibra.io this calendar year but did use @bondhome.io last year - would assume they would normally redirect one to the other but I am not sure and obviously something is not correct at the moment)

EDITS: in italics above

Do you mean

would assume they would redirect

Obviously not…

I don’t believe anything has changed here.

The trust_state device property only appears for devices where there is a toggle signal and thus some ambiguity as to the device state. This is the case for many ceiling fan protocols, but it is not the case for Somfy RTS.

In other words, with Somfy RTS we have discrete Open and Close signals, so we always know the state of the device (assuming the factory remote is not used, and that all transmissions are received). Compare this to the situation for many CFs where every time we send the ToggleLight signal, the light flips state but we need to assume whether it was on or off beforehand to be able to honor a TurnLightOn/Off intention.

1 Like

Chris @merck , I don’t see trust_state for any device (FW v2.10.21):

RCF84 is a so-called “state remote”. Every transmission contains the complete desired state, including light on/off, brightness, and fan speed. So there’s nothing that trust_state would possibly do.

Ok, which template can I use for testing? @merck

RFC84 does haveTogglePower

You can use A1. Or you can “raw record” a remote, and just add a single command for TogglePower.

Of course it does, that’s a guaranteed part of the Power feature. Our API design is that the whole feature (in this case “Power”) is exposed at once. That way the integration can just call TogglePower to actualize that user intent, without worrying about what is programmed.

Thank you Chris @merck - in HomeSeer plugin I now display “Trust State” option only for device which support it.