fritzinfluxdb
fritzinfluxdb copied to clipboard
bb-Ricardo
feat: add connection detail parsing for devices
What does this PR do?
This pull request adds the ability to parse connection detail values for each active network device.
Specifically it adds:
- Is part of Mesh
- Wifi frequency
- Upstream / Downstream speed
What issues does this PR fix or reference?
#65
Functionality Before
The above mentioned device details are not collected.
Functionality After
The data extraction mechanism for device properties has been extended add additional information to InfluxDB.
Data that is extracted is stored in the txt key. Devices can have one or more property objects (usually mostly two like "Mesh" and "Speed"). The JSON snippet below shows the different variations from a Fritz!Box 7490 on Fritz!OS 7.29.
{
"properties": [
// Device is part of Mesh, i. e. Powerline or Repeater
{
"txt": "Mesh",
"link": "",
"class": "nexus text",
"onclick": "",
"svg": "/css/rd/icons/ic_nexus.svg"
},
// Connection speed for non-WiFi devices
{
"txt": "166 / 150 Mbit/s",
"onclick": "",
"icon": "",
"link": ""
},
// Connection frequency and speed for WiFi devices
{
"txt": "2,4 GHz, 50 / 836 Mbit/s",
"onclick": "",
"icon": "",
"link": ""
},
// Connection frequency only (edge case to be aware of, seen intermittently on Repeater device)
{
"onclick": "",
"txt": "2,4 GHz",
"icon": "",
"link": ""
}
]
}
Additionally this pull request also adds a new tag name to certain value entries, so that a value selection based on tag value is possible within Grafana 1.8.
@bb-Ricardo Let me know if that PR suits you. Python is not my main language that I use.
Specifically I'd be interested if there's a more elegant solution to check for the the RegEx value (without using NumPy, didn't want to add another dependency).
Hi,
first of all thank you for this high quality PR. Not seeing a description like this very often.
I had another look at the FritzBox user interface and found way more structured data here: "WLAN->Funknetz".
Example:
{
"pid": "wSet",
"hide": {
"rss": true,
"mobile": true,
"provServ": true,
"liveTv": true,
"dectMail": true,
"dectRdio": true,
"ssoSet": true,
"liveImg": true
},
"time": [],
"data": {
"wlanSettings": {
"protocol": "23",
"hasTriband": false,
"knownWlanDevices": [
{
"type": "active",
"name": "Bathroom",
"delete": {
"deleteable": false,
"reason": "DEVICE_ACTIVE"
},
"uid": "landevice984",
"url": "http://192.168.178.32",
"bands": {
"ghz24": {
"mac": "60:01:94:00:00:00",
"cipher": "wpa2",
"rssi": 5,
"rate": {
"us": "54",
"ds": "72"
},
"props": "n/Wi-Fi 4, 20 MHz, WPA2, 1 x 1"
}
},
"ip": "192.168.178.32"
},
{
"uid": "landevice2137",
"name": "SkyNet-Mainframe",
"delete": {
"deleteable": false,
"reason": "DEVICE_ACTIVE"
},
"type": "active",
"bands": {
"ghz5": {
"mac": "88:66:5A:00:00:00",
"cipher": "wpa2",
"rssi": 4,
"rate": {
"us": "866",
"ds": "1170"
},
"props": "ac/Wi-Fi 5, 80 MHz, WPA2, 3 x 3"
}
},
"ip": "192.168.178.83"
},
{
"uid": "landevice4515",
"name": "Printer",
"delete": {
"deleteable": true,
"reason": "CONFIRM_DELETE"
},
"type": "passive",
"bands": {
"ghz24": {
"mac": "00:22:69:00:00:00",
"cipher": "none",
"rssi": 0,
"rate": {
"us": 0,
"ds": 0
},
"props": "nicht verbunden"
}
},
"ip": "192.168.178.76"
}
]
}
},
"sid": "XYZ"
}
Would rather use this as data input.
For Mesh the page "WLAN->Mesh Repeater" seems interesting. But I don't have any Mesh device, so not sure what we could get out of there.
There is actually way more to get there. Probably worth adding a complete dashboard at the end.
What do you think?
I'm a developer - so a proper PR is a must. Especially in open-source, when random people like me propose additions to a project without having discussed the implementation in detail. ;-)
There is definitely a benefit of parsing structured data. At the same time the data is much different between both endpoints.
See here a comparison between two payloads for the same device, pulled at the same time. The first payload is from the endpoint you mentioned, the second payload is from the currently used endpoint.
| Proposed Endpoint | Current Endpoint |
|---|---|
| holds data for wifi devices only | holds data for all devices, incl. powerline, repeaters etc. |
| holds wifi data in specific JSON structure | holds all network data in specific text form |
| shows us/ds data for actively connected wifi devices | holds us/ds data for all devices based on last connect |
// Proposed endpoint
{
"uid": "landevice120873",
"name": "Badezimmer",
"delete": {
"deleteable": true,
"reason": "CONFIRM_DELETE"
},
"type": "passive",
"bands": {
"ghz24": {
"mac": "F4:34:F0:52:09:23",
"cipher": "none",
"rssi": 0,
"rate": {
"us": 0,
"ds": 0
},
"props": "nicht verbunden"
}
},
"ip": "192.168.178.YYY"
}
// Current endpoint
{
"mac": "F4:34:F0:52:09:23",
"type": "wlan",
"conn_info": [],
"parent": {
"name": "FritzPowerlineXXX",
"url": "/secure_link.lua?sid=9927fe1c05724866&lnk=http%3A%2F%2F192.168.178.XX"
},
"properties": [
{
"onclick": "",
"txt": "2,4 GHz, 59 / 13 Mbit/s",
"icon": "",
"link": ""
}
],
"options": {
"guest": false,
"editable": true,
"deleteable": true,
"disable": true
},
"UID": "landevice120873",
"state": "globe_online",
"port": "WLAN",
"name": "Badezimmer",
"model": "active",
"url": "",
"classes": "wlan",
"ipv4": {
"_node": "entry0",
"addrtype": "IPv4",
"dhcp": "1",
"lastused": "1666852442",
"ip": "192.168.178.YYY"
}
}
The "WLAN" -> "Mesh Repeater" data is only relevant for how one wants to operate the box itself (as master, or as mesh slave). It doesn't represent if a device like a WiFi repeater or a Powerline device is actually active as a Mesh member, so that it helps to steer best connectivity for the connected devices.
You can see here the visualization of an excerpt of my network. The Powerline adapters are Mesh members (see Mesh symbol), and you can get their us/ds data, as well on how the connected devices connected to them. That's a more granular view on how the network operates over time, and how/where there are/have been potential issues. Which is kinda the reason why I'm looking into it. ;-)
Hi,
Good point. Also not a fan of inconsistent data between endpoints. 😄
Then I would suggest to add a separate function which does the parsing with the desired returned value as second parameter. Also should account for "GBit/s" values.
What do you think?
Hi @muenzpraeger,
I just checked again and Gbit/s does not show up in the host view it will report 5 GHz, 1300 / 1300 Mbit/s so just ignore this comment.
I'm finally done with the dashboard conversion to Flux. So I might just merge this as well and rework it a bit.
Sure, whatever approach works best.
As long as I can move off my custom form at some point in the future. ;-)