I have updated today my HA to 2022.02.3 and after some struggle with it, I mean with HA, I have updated your Linksys Velop integration as well through HACS.
And I have had chance to try the new reboot button as well as my node was misbehaving.
And I have to say thank you very much for your development, the new reboot function works like a charm. It has rebooted the node without any issue and fixed my connection problems there.
Thank you!
The 2022.2.3b0 beta release is out. Main things from this are: -
Parent sensor to give info about the backhaul connection2022.2.3b1 is out: -
2022.2.3b2 is out: -
2022.2.3.b3 is out: -
2022.2.3 is now out and available in HACS.
Hey, thanks for your continued work on this. Not sure if you can help, but I’ve been trying to track when my son’s gaming PC is on, and he’s pretty good at dodging detection.
I’ll provide more detail than we need, just incase it adds context or triggers something in your mind that I’ve missed.
First attempt:
I started with a power monitoring socket, but it was easy for him to plug it in via another outlet.
Second attempt:
Then I tried a simple ping checker provided natively in HA:
binary_sensor:
- platform: ping
host: 10.13.1.241
name: "Gaming PC"
scan_interval: 60
That worked for a while, but then he started running his wifi network under the public profile, so ping requests got refused.
Third attempt:
Rather than try to force his profile, I then looked to this velop integration to see if I could get a on/off from the particular device. His PC is known to the mesh, and has a static IP.
Question: Whilst the velop integration creates device_tracker entities for all iPhones that join my wifi, I don’t see anything for his PC. Is there a way I can make it show this device?
Failing that, the most compact version I’ve found to track the device is to ask the node nearest him to iterate the devices that are connected, convert each to a string, and return a 1 if the result includes the text ‘gaming’. I’m sharing the config here:
binary_sensor:
- platform: template
sensors:
gaming_pc_connected:
friendly_name: Gaming PC Is On
value_template: "{% for item in (state_attr('sensor.velop_kids_room_connected_devices','devices')) %}{% if 'gaming' in item | string %}1{% else %}{% endif %}{% endfor %}"
That kind of works, with the following constraints:
Question: is there a better / easier way to track the above so that I get an on/off?
What I’ve got does work, and with the current output I can show the time spent today, and in total over the last ten days using:
sensor:
- platform: history_stats
name: Gaming PC Ten Day ON
entity_id: binary_sensor.gaming_pc_connected
state: "on"
type: time
end: "{{ now().replace(hour=23, minute=59, second=59) }}"
duration:
days: 10
- platform: history_stats
name: Gaming PC ON today
entity_id: binary_sensor.gaming_pc_connected
state: "on"
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
This lets me flash his lights when he approaches his daily allowance, and the ten day tally affords me some discretion via contextualising his recent usage.
TL/DR
The integration is great. It lets me detect if a specific device is connected to a particular node on my network, and trigger actions based upon its presence and tallies of time elapsed within a given period. But am I going 3 sides of a square to get this control?
Cheers!
So there’s a few things here…
Device trackers should work for any device because the integration doesn’t care what they are. That being said I may have introduced an issue where you can’t see offline devices when adding a device tracker - I remember thinking at some point it was an issue but thought I’d solved it. If I didn’t can you raise an issue on GitHub please?
You should be able to use sensor.velop_mesh_online_devices and look at the attributes to get the device. If you query a node directly as per your template there’s a chance that the gaming PC could be on a different node - my phone has a habit of moving nodes.
If you can get a device_tracker for the gaming PC you’ll probably need to create a group, or link to a person because if he keeps switching between Wi-Fi and Wired to try and fool you, you’ll want both being caught.
P.S. new format for the devices attribute in the sensor.velop_mesh_online_devices is as follows…
devices:
- Back Bedroom - HEOS:
ip: 192.168.123.57
connection: Wireless
guest_network: false
- Back Bedroom - Meross:
ip: 192.168.123.195
connection: Wireless
guest_network: false
- Bedroom - HDHomeRun:
ip: 192.168.123.10
connection: Unknown
guest_network: false
- Bedroom - HEOS:
ip: 192.168.123.71
connection: Wireless
guest_network: false
Hey! That’s really neat.
OK. Changing my logic to read:
{% for item in (state_attr('sensor.velop_mesh_online_devices','devices')) %}
{% if 'gaming pc' in item | string %}1{% else %}{% endif %}
{% endfor %}
Now if he’s anywhere in the mesh, it’ll pick him up. I just need to discreetly plug in his network card to get the MAC address of his ethernet port, and reserve its IP address on the Velop so that I can track that too. 
This is much more robust, as there’s always a list returned by the online_devices when HA is running (because its one of them)
Excellent work. Thanks for this!
If you’d like to use device trackers you should be able to. It also shouldn’t matter if there’s a reserved IP. You can just create a person or group to put the two together and base any automation on the state of that entity.
I did check last night and you can see devices that are offline in the device trackers pick list so that should be fine.
There is a downside to the device trackers approach though… it’ll check every 10s (by default) but then not update to away for 180s (by default). Whilst both of those times are configurable, changing them would affect what you’re doing with your normal trackers (IIRC you mentioned using them for presence checking with phones).
The template you have should work fine and there’s no need for a reserved IP either. If you name the gaming PC accordingly on the mesh, e.g. in the Velop app/UI find the device when on WiFi and name it “Gaming PC (WiFi)” and when wired “Gaming PC (Wired)”. Then your template can look for the words “Gaming PC” being in the devices key, as you do now.
That way, the only reason this could fail would be if the Gaming PC MAC address changes and is seen by the Velop as a different device, i.e. it won’t have a name that matches the rule.
Long post but hopefully that helps.
Perfect post, thanks. I use the reserved IP as its tied to his MAC address, so even if he changes his machine name, I can still find it in the connected devices list 
I’ve a few automations that check for things like “the IP is connected, but the device name isn’t there” or “the velop sees the gaming_pc, but pingback says the IP has refused me.” Its this kind of thing that reveals where he’ll try next 
Ultimately, he’s learning a lot about how to cover his tracks.
If you rename the device in the Linksys WebUI or app then it won’t matter whether he changes his machine name at the OS level or not. The Velop will see the MAC and tie it to the same record. So, for example, the “Bedroom - HDHomerun” in the previous post does not have that as a hostname (I can’t set one) and it doesn’t have that name in DNS (would break DNS rules) but I have renamed it in the Velop UI to that (see following screenshot). The machine names you see in the integration are based on what you see or edit in the Velop UI.
Good to know… thanks. So I’ve basically got him pinned until he puts a new network adapter in, discovers spoofing or locally administered MAC addresses 
Or finds out that he can tether to his phone and send his mobile bill through the roof just to bypass your router. 
2022.3.1b0 is out: -
DataUpdateCoordinator
device_tracker consider home functionalityThis is basically a maintenance release but… it has the potential to break some things so all testing is appreciated - I have however fixed everything I’ve found in testing.
2022.3.1b1 is out: -
Quick release sorry… I found an error being logged in the data update (didn’t affect the data) but it only appeared to be happening when disabling the integration.
DataUpdateCoordinator
device_tracker consider home functionalitynext rather than submit where appropriate2022.3.1b2 is out: -
DataUpdateCoordinator
device_tracker consider home functionalitynext rather than submit where appropriatepyvelop version to 2022.3.2
select entity for devices2022.3.1 is now out and available in HACS.
2022.3.4b0 is out: -
Breaking Change: Allowing multiple instances has meant I’ve changed the way services work slightly. You now need to provide the device ID for the Mesh when calling a service. The service definitions have been updated to reflect this.
2022.3.4b1 is out: -
Breaking Changes
2022.3.4.b2 is out: -
2022.4.x)Breaking Changes
2022.4.x the binary sensors and sensors detailing versions will be removed and replaced with the a new update sensor so any automations or UI elements will need to change accordingly. Whilst running anything earlier than HASS 2022.4.x you should notice no change.2022.3.4 is now out and available in HACS
2022.4.1b0 is out: -
current_version to accommodate 2022.4.0b3
pyvelop to 2022.4.6
auto_update property of the update
2022.4.1b1 is out: -
current_version to accommodate 2022.4.0b3
pyvelop to 2022.4.6
auto_update property of the update
The bump to pyvelop 2022.4.6 is quite a big one. The library has undergone some large restructuring in anticipation of making the repo public.
All testing on this beta would be greatly appreciated.
Hi uvjim!
Thank you for all of your hard work on this - it’s very much appreciated. The latest beta seems to be working great - no issues at all.
I noticed a few weeks ago that an ‘Additional Information’ entry was showing in the lovelace card, which listed the backhaul type/speed - has this been taken out?
It actually appeared at a perfect time - turned out the wireless backhaul link between 2 nodes was a bottleneck. An ethernet cable through the loft has now solved it
Thanks again.
It should still be there. The following screenshot shows what I see here.
Could you check the attributes for the parent sensor on a node that is not the primary? You should see something like this: -
That should tell you the data that should be supplied.
Thanks for coming back so quickly!
You’re right - the attributes for the parent sensor are showing the backhaul type/speed - thank you.
Strangely, the ‘Additional information’ element isn’t showing (I recreated the card this morning from your GitHub yaml to make sure I was running the latest version), and I notice that the Parent node is showing as ‘Unknown’ on the sensor attributes:
I’ll investigate some more. I’m running the WHW03B units. Thanks again.
The highlighted section in the card config is what is stopping it showing…
The card deliberately stops an unknown state from showing - that could probably quite easily be changed.
However, assuming that the node isn’t the parent (which it can’t be because it has backhaul info) we probably need to find out why the parent name is being calculatd.
Assuming you’ve updated to the latest beta version the diagnostics should be working again. If you click on that you’ll get a JSON file. Double check that file has no personal information in it (hopefully it shouldn’t, I’ve redacted a fair amount in there). Feel free to send it over and I’ll see if I can work out why the parent node isn’t being matched up.
Many thanks - the ‘unknown’ parent explains why the details aren’t showing. It won’t let me post the diagnostic information here (more than 32k characters) - is there a better way for me to send it to you?
Feel free to attach it to an issue in GitHub. I can pick it up from there.
2022.4.1b2 is out: -
2022.4.6
2022.4.7
2022.4.1b3 is out: -
2022.4.6
2022.4.7
update entity picture now uses constants2022.4.1 is now out and available in HACS