#devs_zwave-archived
1 messages · Page 35 of 1
Or maybe they get sent immediately but for sleeping nodes they come back un-acked 99% of the time
Pings are not queued in the wakeup queue
So the only thing I can imagine here is that the node fully wakes up while reporting unlike some others, and the ping forces the driver to notice
Must be the case... nothing is ever as it seems with Z-Wave.
Interesting
I agree with this. I also understand the value of querying the info rather than caching it but it still leaves the problem of sleeping devices - we could detect that the device is not responding and ask the user to wake the device up, but they would potentially have to do it twice, once to query the capabilities, once to initiate the firmware update. If the concern is that the cache will be stale then that's not the right solution. But if the firmware update capabilities only change on firmware updates (in theory) and devices are automatically reinterviewed after a firmware update thus updating the cache, relying on cached values seems safe? We would just need to hide the actions while the device is being reinterviewed which we should do anyway
CC @covert gate
...and I just saw that you added a comment to the frontend PR proposing exactly that
I mean sure we can do it, it just seems like an inconvenience IMO
https://github.com/zwave-js/node-zwave-js/pull/4779 @slender reef
I just opened my first PR that would fix an erroneous ZWave device mapping. How can I test the changes locally?
I have a Supervised HomeAssistant running.
On my own, my bet would be to:
- Get into the HomeAssistant Core docker container
- Make the same changes I have in the PR
- Deregister the ZWave device
- Re-register the ZWave device
- Check that is works and is identified as it should be (barrier, instead of light)
Is there a simpler way?
- Can I ask Supervisor to use my own docker image for HA?
- Do I nee to deregister/re-register the device to test the changes?
I added a comment. Why don't you setup a dev environment somewhere else?
Exposing port 3000 in your add-on, then running a dev HA environment on your local PC and connecting to it is much easier, IMO.
👍 Thanks for the idea. That's why I was asking. 🙂
Is my assumption correct, that I need a custom data_template as in https://github.com/home-assistant/core/blob/d27e89c773bfc5a43a31a6345ec0e4547f89f1cf/homeassistant/components/zwave_js/discovery.py#L332 to get around the limitations you highlighted in your comment?
That seems to be the approach that's been taken so far for other devices, so it might be accepted without objection.
You could wait for some feedback from core devs if you want.
I don't quite understand the data template stuff myself, TBH. They're all done a little differently.
Basically you need an abstract way to get and set the states
Yeah, I was just looking at the code for data templates and I have only wild guesses what they might do. Are these data templates use to generate the config for https://www.home-assistant.io/integrations/cover.template/ ?
No, nothing to do with that.
That was my worry. It would be nice to be able to track how data flows through the system.
cover template is a completely different integration. not really sure what you mean.
I was thinking if I can reach both the current value and target value in HA or only in ZWave.js. If they would be available in HA, I'd be able to use the cover template to know the correct state. Otherwise, this needs to happen within ZWave.js, that I know much less about.
The cover template could only work with MQTT
Err, sorry. You can wrap the light entity in a cover template.
Well, it's hard...
You can trigger off of any value in a template
I'd prefer to leave out MQTT for now 😦
I'll try to implement the custom data_template
Thanks for all the infos!
Ohh, if I understand the linked docs right, this might be feasible without MQTT. Thanks!
You don't need mqtt if you want to go the template route (although it's probably easier).
@timber latch happy to walk you through the data discovery template logic if needed. The idea is that some devices need more complex discovery mechanisms to capture the right values/data to create the entity. Instead of complicating the discovery logic, we added this helper to attach the necessary data to the appropriate discovery info
Thanks! I looked into the code a bit and I don't think that the data_template provides the necessary flexibility in this case. For this reason, I closed the MR. Let me know, if I am wrong, and I can give it a second try.
it's usually a combination of the data template and a new platform entity class combo that does the trcik
without having looked too deeply into this I think it does fit your use case, but I will review the description in more detail and get back to you
@covert gate looking at the automatic firmware update logic some more, doesn't seem like there's a good way to add a property on the node that indicates whether it would support automatic updates or not is there?
since you are live querying all of the manufacturer/product data
Correct
The main concern of manufacturers is users installing a wrong firmware and bricking their devices with it.
That's why I'm not going to rely on cached info here
You can schedule the check for the next wakeup though
@wild halo you think it would be OK to add an update entity for every device then? ^ we have no way of knowing whether it will be useable or not
I think that's ok, yes.
I guess we'll wait until we have the first manufacturer on board to introduce it then
Can you add it dynamically? E.g. remember if the check was done yet for a sleeping device, if not use waitForWakeup to schedule it.
Also the update DB info can change over time, so it might be that an update shows up or disappears after the initial check.
I don’t think that would lead to a good experience. If anything restarts it would “forget” and start over. Better to just create the entity and most will say no update
That will also handle db changes properly
waitForWakeup is an interesting idea though because I was trying to figure out how to handle sleeping devices
What solution would be accepted for this issue? https://github.com/home-assistant/core/issues/54631
So simple fix, removing the error check for a missing value if it's Basic CC?
More elaborate fix: add a multicast invoke_cc_api
Should still be a valid value, I.e. targetValue
The driver doesn't expose Basic values though, that's the problem
Good point
I hope to remember that when finishing v10
Although I think it should expose them for virtual nodes, I.e. Multicast
Yeah, you did add that, but HA doesn't use them. It sends the list of nodes to the server, which creates the virtual node there. HA (python lib) is validating that each individual node has the Basic targetValue.
Ahh
Hey all – so, the time has finally come and there has been a lot of work going on behind the scenes that’s taken much longer than anticipated and there’s still plenty to do. However, I wanted to give you all a quick announcement and status of the company. Earlier this week, we executed a contract between us and another IOT group. I thought we ...
oh wow
Not shocking given their lack of revenue this year. The chip shortage really hit them as they seemed unable to produce anything to sell. Given that others can still get zwave chips, that suggests a troubling lack of resources
i kinda wanna try their zigbee switch out ... lol
Awesome. Should the non-multicast case be handled the same way?
OK so fix the set_value service for Basic CC, we clearly don't support associations, is there anything else major we are missing support for right now?
network health
NVM backup/restore
Apparently ZHA has the latter already (or is getting it soon)
backup/restore?
backup restore would be easy enough to add. Network health would be a bit trickier
yeah
Zigbee, if I recall, also doesn't store pairings in the stick so there's not NVM to backup, so just a file backup is required.
Don't quote me on it as I only started playing with zigbee so far 😛
thinking again, an entity doesn't seem like a great experience. since battery devices sleep, interacting with the entity will be confusing, as the value will always revert until the device wakes up. if it's another setting in the configuration, you can display a message like config params.
That’s right I think. I def nuked the db once and had to start over
So I have 2 zwavejs integrations configured, if I do an "Add Zwave Device" from the menu here, which integration does it try to put into inclusion mode?
whichever is listed first in the config entries
Maybe that should not be shown when there is more than one integration?
i agree
@wild halo @slender reef the v10 migration guide has grown quite a bit since I last shared it:
https://zwave-js.github.io/node-zwave-js/#/getting-started/migrating-to-v10
Might be worth taking another look
The migrating link above is a "page not found"
fixed
Only 40k changed lines (excluding lockfiles)
How would the update API keys work if you're not running the HA add-on, or zwavejs2mqtt?
If you're using HA, just use its key?
how would you be executing the driver then?
Manually, or in a custom docker container. I'm not currently, but I have my own container that I'm building, might some day...
Heh, sure. I'll post a link to the docs in my README.
this is mainly to keep commercial applications from just using the service without thinking about this
as they now either need to request a key, willingly steal one or not use the service
Understood. Apparently some people are using my docker container. Unless there's some bot pulling the images. Somehow has over 500K pulls, and they aren't me.
probably make it configurable and put it in the readme that the key needs to be configured
That's the plan.
not sure whats easiest, but I guess I can give you a key so you can tell users to:
a) use that key if private use
b) request one if commercial
I'll keep that in mind, thanks! Might depend on how HA supports it though, if it's done through API like statistics.
or maybe they just hardcode it in the add-on
thats likely the easiest
indeed
sounds like some company was trying to be naughty eh?
nah, thats just us being cautious
who has HA's key?
and how secretive do you want us to be? do you want it to be a secret that gets added during package build or can it be stored in source?
also do you expect 10 to get released in the next week?
that's when beta starts so trying to decide whether or not to get the server ready for that
Zjs2mqtt’s key will be hard coded in the clear, so I’m not sure it matters that much
If it’s added at build, then you couldn’t make a dev instance, right?
I guess that’s fair
Any thoughts on this @covert gate
I'd suggest we save 10.0 for September release.
Fine by me. Not sure how much will come up this time.
To be clear, I mean the Home Assistant September release. The driver can/should be released before that and then we need to update the server and client libraries, and add-ons, besides Home Assistant. Aiming for September, with beta release 31 August gives us 5.5 weeks to do this instead of 5 days.
Beta.2 is already out, so from my side it's just a matter of testing it