I will give this a shot and see. This ‘could’ significantly reduce the size of my binary_sensors.yaml which is mostly ping sensors for devices on my network.
Looking at the README, I assume that primary node address is the ip address in standard xxx.xxx.xxx.xxx, is that correct?
Certainly is. It should be the address of the primary node as well. Whilstvwriting this I fell foul of accidently using a secondary node at one point and found that some of the calls I’m using required the primary - so I’ve made that a requirement now.
You guess correctly. I’ve only seen that happen if the translations aren’t loaded correctly. A forced refresh of the browser normally diets that for me. Looks like you’re using the companion app, so maybe force closing it and reopening might do the trick.
Looks good so far.
The ‘Mesh’ entity for location, I’m not sure about. I left it blank for now and put in the locations for the actual nodes.
I’ll work on my view and redoing some of my automations and see how it works.
I haven’t put an area against the mesh device either. The nodes have areas though. To be honest it doesn’t really make a difference for the way I use it either.
I felt like the mesh needed to be a device separate from the nodes mind you as it represents the majority of things that you’d interact with or have info about. I typically only use the nodes for status (to know if one dropped) or if one doesn’t have any connected devices at all.
I’m waiting for Linksys to release another firmware update so I can finalise the sensors for newest version and update available (I had those working with the pyscript integration previously so I know roughly what needs to be done).
Edit: unless you meant the device trackers… In which case, I find that useful in conjunction with the companion app. My phone will drop WiFi and show as not_home according to the consider home timing. The companion app will handle GPS. I was using the companion app and it’s WiFi connection sensor but found that occasionally took a while to update.
I’ve just pushed another update which adds a few more things. Most importantly it adds the ability to detect if a firmware update is required. However, whilst testing this I found that the Velop can sometimes get a little upset and have a node in the mesh that is fully connected, accepting connections, is not the primary but doesn’t report a parent node - in fact it reports that it is connected to parent 0.0.0.0 which clearly isn’t right. I’ve had to fix/workaround that in the underlying library as well.
I’m currently resetting the node in question to see if that brings it back to life.
I still need to update the README (mainly because I forgot) to bring it inline with the changes.
Thank you so very much!
I joined the Home Assistant world just a month ago (changing from SmartThings). I’ve been trying to get my Linksys AC2200 Smart Mesh Wi-Fi Router to connect. This works great! Even sees the Velop router I have meshed to the main router.
Most Excellent!
There might be a flurry of updates coming out as I had to do a full reset on the mesh the other day and found a few issues where responses weren’t quite as I expected (they were fine for a system that had been up and running for a while).
Pretty sure there’s nothing breaking though - most of it is guarding against responses being empty or not available.
Good news is that I now have a single node that can be used for testing and reset at will.
Just a heads up. I’ve pushed a new release today. The only real things in there are preparing for the HASS 2021.11 release. They shouldn’t break anything mind you so just raise an issue on Github if you spot anything.
This is the new functionality added. Essentially I’ve made all binary sensors and sensors have the diagnostic category.
The Mesh device will also have the configuration_url set so that it’ll link to the primary node.
You may have spotted that there’s a couple of big things hiding in there (UPnP support and preventing duplicates). You shouldn’t really notice these but they mean the following…
For those that remove the integration, or are new users, the primary node should now be automatically discovered for you. When you configure you will still need to supply the password, timer details and select your device trackers.
Switches have now been given the configuration category which should help with the layouts in Lovelace.
For those interested in what happens when adding the integration for new or existing users and when duplicates are prevented, I’ve written up what I’ve tested: -
New (manual) = created with unique_id
New (SSDP) = primary node automatically populated, created with unique_id
Existing (no unique_id, SSDP enabled) = unique_id populated when discovered
Existing (no unique_id, no SSDP) = no unique_id
Existing (no unique_id, no SSDP, try to add duplicate) = unique_id populated, duplicate aborted
Existing (unique_id, try to add duplicate) = duplicate aborted
The unique_id in each case is the serial number of the primary node. This was made more awkward by the fact that I missed adding the unique_id in the initial releases. Hopefully no-one should even notice a difference mind you. This essentially means that if you replace your primary node, then you’ll probably be safer removing the integration and re-adding (unless you fancy manually modifying the YAML file for config entries).
Hello
I really liked your Lovelace layout and would like to use it, but when I copy the yaml and paste it in my lovelace I get all kinds of errors. I guess most of them are errors on intendations, but it is hard to see them all with so much code. Is there a way to just copy into the file and it works? I have installed all the cards you have used as well
