According to the release notes it looks like I added some more checks into the process in 2021.11.2. There was also some debugging added.
I’m not running in bridged mode so can’t do any testing myself.
Have you double checked using the right password? The last report of infinite spinning when adding the integration was down to the password not being that of the router but the cloud service. The credentials needed are those of the router.
Failing that, if you can enable debugging and send a log over I can have a look through it.
@uvjim, never mind. It miraculously started to work after I put http://IP_ADDRESS and that failed the connection. After just putting the IP_ADDRESS just loaded the rest of the configuration steps correctly.
It reports things, but the amount of connected and not-connected devices is a bit incorrect.
That’s good to know. I can test using that format here.
In what way are the counts not right? The integration asks the router what is connected. From there it determines which devices are connected to which node.
I have seen the following happen though…
The router responds with a full list of connected devices bit I cannot determine if they are connected by WiFi or cable because the information isn’t there (the Linksys app seems to assume they’re wired). When this happens the information for determining which node the device is connected to is very often missing as well.
Now, when this happens, after a while the information does get updated on the router. This can take hours, days or sometimes weeks.
So, it was not connecting with http, and that might triggered something when I tried again without http. So, I have no clue what has went wrong before with the continuous spinning…
The counts are weird generally, it lists for me 10 connected devices, when there is about 20-30 (maybe more) devices permanently on the network.
And it lists 75 not connected devices, and it even doesn’t show what are they, just Network Device.
I think it might be due to the bridge mode. That handles things quite weirdly.
As far as I am aware, no. I haven’t seen a way of doing this in either the web UI (the one on the router itself) or in the Linksys mobile app.
As per the web UI or the mobile app, if the device name is not determined it falls back to using “Network Device”. I have hard coded that text, but could make it configurable. However, if you want the correct name to show then you should change it in either the web UI or mobile app.
Correct. There isn’t a public repo for that code yet. When I first started building it, the code was very messy but served it’s purpose. It was in a state of change for a while but I knew it could service the integration without issue. I’ll probably make it public at some point but just haven’t gotten round to it yet.
There is a button to restart the Velop system in the app, and it is available in the web UI as well, under the Diagnostic tab. If you force your connection to one of the nodes and not to the main one the same button is available as well in the web UI and as far as I know it restarts only the actual node.
I’ve found this Golang code which says there is an option in the JNAP API for reboot:
Ok, that makes sense. If the devices are running in bridge mode then there isn’t too many options in the Web UI. Neither in the app…
As you point out the button in the Web UI and app is to restart the whole mesh. As is detailed in the subsequent prompt.
If I did put this in I could do it as a service or the new button entity. It would need a change to the pyvelop library to support it as well. What would be your use case for it?
I’m not sure that the reboot method on the Velop takes any arguments so my assumption is that it would restart the whole mesh rather than just the node you’re connected to. You’ll notice that the integration checks to ensure that you are connected to the primary node. This is because some of the methods used to gather the information only work on the primary node.
It was just the normal IP 192.168.X.X. Then I tried with the http that seemed to make things “working” as it showed a connection error, then when I tried again the IP it was working and going to the second step where you define the time values. I cross checked the password multiple times and it was correct. It just seemed to be not going further to the second step of setup.
One of my nodes behaves weirdly. It drops connections and puts them to a connected/not connected state. So it does some weird things and I cannot find out why. So, time to time, I have to restart it and that fixes things. Otherwise, when I am away from home, I can do this only through the Linksys app, but that does restart the whole system.
I’ve just published version 2022.1.3. This version should not cause any issues at all. The release just adds support for the new Diagnostics integration coming with HASS 2022.2.
I’ve tested this my side and all seems to be fine. I think I’ve ensured all PII is redacted but if you look at the information in there and I’m missing anything just let me know and I’ll get that added to the redaction list.
I have two nodes that occasionally go weird and drop (they typically come back onto the mesh themselves) - I can track that using an automation for the state. All devices behave as they should and move to another node mind you.
When this happens a few times I just power them off at the socket and back on again - luckily the main culprits are plugged into ZigBee sockets.
I still haven’t had a chance to to check if you can tell a specific node to restart mind you but will hopefully get a chance to check that soon.
Unfortunately my node is a satellite device, actually in the cellar. The sysinfo.cgi shows some weird behaviour of the devices close to it. When I am away from home it is hard to restart the node, but has to happen time to time. The webinterface allows individual device restart, but it is quirky. You have to force connection to the individual nodes and not to the master. Actually that is a way to force different wifi settings to the nodes as well.
I’ve just made a direct connection to a node’s web UI and restarted that particular node. The UI warning is a little misleading in that case. It implies that all nodes will restart but that doesn’t appear to be the case.
I’ll create an enhancement on Github to track this. I’ll look to build a service that can target a node to restart it. This will obviously rely on the fact that the node really is reachable.
I’m not sure how long it will take me to do and it may need some changes to the underlying library - that currently uses only the primary node. I’ll also need to check what impact restarting the primary node has - I have a sneaking suspicion that it will restart all nodes.
My suspicion is confirmed. A reboot of the primary node causes a reboot of the secondary nodes if this link about the meaning of the lights is to be believed.
With that in mind I’ll look to put an additional hurdle in for a reboot of the primary node. The hurdle maybe as simple as setting a flag to accept that you know the risk, i.e. all nodes rebooting (currently not sure whether I’ll do this at the library or integration level).
I’ve already made the pyvelop library do a reboot in the simplest way I could think of without a large recode. Basically you ask the mesh class to carry out the reboot. The method will then check that the node given is a valid node registered on the mesh, and has an IP address before sending the reboot command. This is only allowed for a subset of JNAP actions (currently I’ve made it only possible for the reboot action) because I don’t really want/need arbitrary actions being sent to nodes at this moment in time and I know that some of the JNAP actions are rejected by secondary nodes.
If you have any thoughts feel free to let me know before I get too far.
Good news. I have a local copy of the reboots working in HASS now.
It currently works in two ways: -
A domain level service that accepts two parameters: node_name and is_primary - this allows you to pass an arbitrary string to the service as the name. The name will be checked by the pyvelop module to make sure it is valid. If it is, and the node is a primary node, it’ll check the is_primary parameter to see if it’s set. If it is, then all is good. If not the restart request is rejected.
The new Button entity is used. If available, Button entities are created for all secondary nodes. They are only created for secondary nodes, so that the primary isn’t accidentally rebooted from the UI. It also means that you can use the button.press service to carry out a reboot as well (or just the service mentioned in item 1).
Hopefully this will give you what you need, with the added bonus that it isn’t easy to accidentally restart the primary node. In fact, the only way to restart the primary node is to use the service.
I have some other updates, bits of tidying and testing to do but hope to get it released soon.
I’ve released a pre-release/beta version of the updated integration now. There’s been quite a few changes and the underlying pyvelop library has been bumped a few times to get the support in.
I’ve tested the pre-release as a new install on latest HASS release, a new install on the upcoming 2022.2 HASS release (I’ve also included some new functionality for that version) and as an upgrade on the current HASS release and current integration release.
It all seems to be working with the additional functionality.
If anyone wants to give it a go, make sure that you enable the ability to see beta versions in HACS as per below…
Feedback is welcomed. Especially if I’ve inadvertently broken something!
I shall update the README ready for the full release.
New Node sensor for seeing the last time firmware updates were checked for (this is disabled by default)
Removed the Mesh “Check for updates” binary sensor because it wasn’t really doing a lot
Added a Button entity in the Mesh to check for firmware updates
UPDATE 03/02/2022: I’ve now released this HASS 2022.2 has been released and I haven’t seen any issues in the various tests and time I’ve been using it.
