[APP][Pro] Vision Security

Apps
, ,
161

Sorry dont know how i can see that. I can see the node and its path and that it is unsecure but no battery.

162

hmm alright. I do see more messages on the forum about battery status.
Did it work before?

163

Yes in the prev V4 it was working. Strange. You are doing the outmost…

164

Maybe it is a V5 thing. All my other battery divices are working good (zwave but also kika as al mij zigbee is working good) BUT dit not pair new devices in 5 yet…

165

I have to go to work. I read you tomorrow THANKS a lot man

1 Like
166

Yeah same here, don’t have any Z-Wave but all my RF and Zigbee devices are working well.
I almost think it’s a ZM1601 thing because the other device do report correctly.

I think i’ll submit the app for go-live and fix the battery afterwards

Thanks for your help with testing, appreciated!

1 Like
167

New app update (test: 2.0.20 ):

  • NEW: add ZM1621
168

New app update (test: 2.0.22 ):

  • OPT: updated ZG8101 icon
169

If a battery device is a FLIRS device, then Homey will give the battery tag as false as it is pretty much hardcoded in Homey that battery devices are asleep, and they work around it with this.
That shouldn’t stop the battery report coming in, and being processed though.

1 Like
170

Even the icon is now looking good. Minor of course, but still nice :nerd_face: . Great work with this app :+1:t2::+1:t2::+1:t2:

1 Like
171

Thanks @Caseda ,:smiley:
I used the default capability from the node-homey-zwavedriver. Which uses the same battery report functionality as the previous version of this app.
Do you have any idea why that wouldn’t pick up battery reports?

172

Sadly I’m not sure, haven’t seen any other brands having the same either (zwave at least).

Could people that have the question mark issue copy over the battery capability’s value that is mentioned in developer tools → devices, I’m curious what their actual value is of the measure battery capability.
Perhaps it is in an invalid state and need to reinitiate the capability with some code, or it might be a bug in Homey that it won’t let the capability’s value be updated in its current invalid state.

1 Like
173

@martijnpoppen In my situation the battery never worked. Patrick’s programming skills where not that far to make this work, as i understood from his replies years ago. It would be awesome if you can make it work, but this isn’t a show stopper for a production release of this app.

@Caseda

Screenshot 2021-03-11 094220
Screenshot 2021-03-11 094220830×183 6.71 KB

174

Yeah, a value of “null”, have a feeling a bug snuck into Homey that doesn’t take into account the value being “null” which isn’t a valid number value but called an “object” making the capability also expecting an “object” instead of a “number”, so giving an error “invalid value type” (and as that is parsed in a layer lower then the app it won’t show in the log/CLI).
Have thrown it up as possible bug at Athom, lets see what they have to say.

1 Like
175

Thanks a lot @Caseda .
Z-Wave is still quite new to me so didn’t figure this out :stuck_out_tongue:

176

This not very zwave related though, seen multiple reports in the Xiaomi app which is zigbee.

1 Like
177

Ah so it’s a type error in Homey.

178

New app update (live: 2.0.24 ):

  • Vision security for V5 (SDK 3) is live!
179

If it’s a bug in Homey, it’s there for many years. I will report it to their support department.

180

It hasn’t been there for years no, might be that your case isn’t the same as you think it was, if it never worked, yours seems more likely that your device just never send a battery value, the issue I’m talking about is more the case if it did work before, but stopped after updating to Homey v5 like in Peter’s case.
You probably need to re-pair your device to fix it.

Now I’m still curious if the value is also “null” for Peter :upside_down_face: