External integration - Unify network

Development
61

Thanks @mutmut for the screenshots, it helps a lot!

The connected clients of the widget are the WireGuard clients of the server: in your case, the UX of Nantes and the UDR of Liège, connected as WireGuard clients to the UDR7. These are not the Wi-Fi or Ethernet clients of the access points. Your two WireGuard servers, « WireGuard Nantes » and « WireGuard Liege », are correctly displayed; it’s the counting of their clients that doesn’t work.

  • First widget : in its settings, the UDR7 gateway device is selected, not one of the two « VPN WireGuard » devices. The widget then displayed the first server found, Nantes. With 1.8.1, it clearly states that the selected device is not a VPN server. Choose « VPN WireGuard: WireGuard Nantes » or « … Liège » and it will be fine.
  • 0 connected clients : I was looking for WireGuard clients in the list of clients in the console, and your console does not put them there. Ubiquiti’s documentation does not say where they are stored. Version 1.8.1 therefore adds a VPN Diagnostic action on the integration page. It queries the few possible locations and only returns field names, numbers, and HTTP codes: no addresses, no keys, nothing personal. Can you run it while Nantes is connected and paste the result here? I will then know where to read your clients.

Update from Gladys :slightly_smiling_face:

62

Updated to 1.8.1.
The opposite is happening: UDR7 is the server, UX and UDR are the clients, but the widgets show the opposite:

image
image675×133 23 KB

For UDR and UX, these are exactly the same screenshots as before.

For VPN diagnostics:

WireGuard servers: 2; active clients (stat/sta): 41
stat/sta keys about VPN: last_uplink_remote_port
#1 enabled, subnet set; in subnet: 0, same network_id: 0
  networkconf keys: _id, dhcpd_dns_enabled, dhcpd_start, dhcpd_stop, dhcpd_wins_enabled, enabled, external_id, firewall_zone_id, interface_mtu_enabled, ip_subnet, ipv6_subnet, local_port, mss_clamp, mss_clamp_ipv6, name, purpose, setting_preference, site_id, vpn_binding_mode, vpn_client_configuration_remote_ip_override_enabled, vpn_type, wireguard_id, wireguard_interface, wireguard_interface_binding_mode_ip_version, wireguard_local_wan_ip, x_wireguard_private_key
  /api/s/{site}/stat/remoteuservpn: 1 item(s): assoc_time, id, interface, last_seen, network_id, peer_id, remote_ip, rx_bytes, rx_packets, rx_rate, site_id, tunnel_ip, tx_bytes, tx_packets, tx_rate, up, uptime, user, vpn_type
  /v2/api/site/{site}/wireguard/<id>/users: 1 item(s): _id, allowed_ips, interface_ip, interface_ipv6, name, network_id, public_key
  /v2/api/site/{site}/wireguard/<id>/clients: string
  /v2/api/site/{site}/vpn/connections: object: connections
  /v2/api/site/{site}/clients/active: 41 item(s): anomalies, assoc_time, authorized, blocked, display_name, fingerprint, first_seen, fixed_ip, gw_mac, hostname, id, ip, ipv6_address, is_allowed_in_visual_programming, is_guest, is_wired, last_seen, last_uplink_mac, last_uplink_name, last_uplink_remote_port, latest_assoc_time, local_dns_record, local_dns_record_enabled, mac, model_name, name, network_id, network_members_group_ids, network_name, noted, oui, rx_bytes, rx_bytes-r, rx_packets, site_id, status, sw_port, tags, tx_bytes, tx_bytes-r, tx_packets, type, unifi_device, uplink_mac, uptime, use_fixedip, user_id, usergroup_id, virtual_network_override_enabled, virtual_network_override_id, wired_rate_mbps
  /integration/v1/sites/<site>/clients?limit=200: 41 item(s): access, connectedAt, id, ipAddress, macAddress, name, type, uplinkDeviceId
#2 enabled, subnet set; in subnet: 0, same network_id: 0
  networkconf keys: _id, dhcpd_dns_enabled, dhcpd_start, dhcpd_stop, dhcpd_wins_enabled, enabled, external_id, firewall_zone_id, interface_mtu_enabled, ip_subnet, ipv6_subnet, local_port, mss_clamp, mss_clamp_ipv6, name, purpose, setting_preference, site_id, vpn_binding_mode, vpn_client_configuration_remote_ip_override_enabled, vpn_type, wireguard_id, wireguard_interface, wireguard_interface_binding_mode_ip_version, wireguard_local_wan_ip, x_wireguard_private_key
  /api/s/{site}/stat/remoteuservpn: 1 item(s): assoc_time, id, interface, last_seen, network_id, peer_id, remote_ip, rx_bytes, rx_packets, rx_rate, site_id, tunnel_ip, tx_bytes, tx_packets, tx_rate, up, uptime, user, vpn_type
  /v2/api/site/{site}/wireguard/<id>/users: 1 item(s): _id, allowed_ips, interface_ip, interface_ipv6, name, network_id, public_key
  /v2/api/site/{site}/wireguard/<id>/clients: string
  /v2/api/site/{site}/vpn/connections: object: connections
  /v2/api/site/{site}/clients/active: 41 item(s): anomalies, assoc_time, authorized, blocked, display_name, fingerprint, first_seen, fixed_ip, gw_mac, hostname, id, ip, ipv6_address, is_allowed_in_visual_programming, is_guest, is_wired, last_seen, last_uplink_mac, last_uplink_name, last_uplink_remote_port, latest_assoc_time, local_dns_record, local_dns_record_enabled, mac, model_name, name, network_id, network_members_group_ids, network_name, noted, oui, rx_bytes, rx_bytes-r, rx_packets, site_id, status, sw_port, tags, tx_bytes, tx_bytes-r, tx_packets, type, unifi_device, uplink_mac, uptime, use_fixedip, user_id, usergroup_id, virtual_network_override_enabled, virtual_network_override_id, wired_rate_mbps
  /integration/v1/sites/<site>/clients?limit=200: 41 item(s): access, connectedAt, id, ipAddress, macAddress, name, type, uplinkDeviceId
63

Thank you so much @mutmut, your diagnosis was exactly what was needed!

It shows that your console puts WireGuard connections in a separate list, and not with the other clients. This is fixed in 1.8.2: connected clients are read from the active VPN connections of the UDR7, and named as in UniFi. In your case, the server « WireGuard Nantes » should display 1 connected client (the UX), with the data exchanged, and « WireGuard Liege » 0 as long as the UDR is turned off. The « VPN Client Connected / Disconnected » triggers also work for them.

For the widgets, I understand the confusion: the two « VPN WireGuard » devices are both on your UDR7. These are the two WireGuard servers you created there, one per site. They do not represent the UX or the UDR. The « udr7 » device from the list is the gateway itself, not a VPN server, hence the message from the first widget. So:

  • widget « VPN WireGuard: WireGuard Nantes » → is Nantes connected;
  • widget « VPN WireGuard: WireGuard Liege » → is Liege connected.

Update from Gladys, and let me know if Nantes appears correctly :slightly_smiling_face:

64

Bingo, I got it, thanks!

It’s perfect:

image
image662×377 38.8 KB

Well, if I dared, I’d also ask you for the live (or almost live) throughput in addition to the traffic (if possible) :wink:
I also think we can switch to Go when it exceeds 1000 Mo and To when it exceeds 1000 Go.
By the way, is it a daily or cumulative counter?

65

@mutmut Top, thanks for the feedback ^^

It’s done in 1.8.3: beyond 1000 MB, traffic switches to GB, and beyond 1000 GB to TB. Update from Gladys.

For your question: it’s not daily, it’s the cumulative data of the client’s current connection, as the console provides it.

Live throughput, I’ll note that: the console doesn’t provide it directly for the VPN, it would need to be calculated between two readings. I’ll look into it.

66

1.8.3 is the best!
image

67

I found another small issue… see my screenshot. In the activities, the integration reports presence for all my relevant devices every single minute. While this is technically correct, it’s completely unnecessary as it floods my activities log. (It’s not a system log, but something useful.) It would therefore make sense to only log this in the activities if no presence was detected before. Otherwise, I have at least as many logs in the activities log per minute as the number of devices I’m monitoring. Not ideal :slight_smile:

image
image1920×1209 152 KB

68

I noticed a small issue: If I use a scene to set a person’s presence status based on the device status, there is a delay — an undocumented delay.

Why? Because the presence of this integration apparently has a fixed value of 5 minutes before it marks a device as away. That means my scene must not check if a device has been marked as away for 5 minutes, otherwise it ends up taking 10 minutes: 5 minutes delay in detection by the Unifi Network integration until it is marked as away, and then another 5 minutes delay until the scene states that this device had the status away.

My suggestion: Make the time until a device is marked as away (e.g., when leaving the Wi-Fi) adjustable. :slight_smile:

69

@stefanbauer Thanks for the two feedback messages!

Delay until „absent“: This is already configurable, in the configuration under „Absence delay (s)“ (default 120 s). With 1.8.4 (update via Gladys), 0 now also works: Previously, 0 was silently taken as 120 s. However, a remainder remains on the UniFi side: The console only reports a phone as disconnected when it no longer sees it (WLAN inactivity), which can take a few minutes, I have no influence on that.

Activities log: Presence is intentionally resent every minute because the Gladys scene action that checks a user’s presence only looks at the timestamp of the last value. Gladys’s built-in network scanner does the same. I’ll look into how to solve this more cleanly and get back to you.

70

Thanks @guim31

Regarding the first point. Ah, we have a similar issue in the scenes for the action « Check user presence ». If you enter 0 for the delay there, no error occurs, it is saved silently, but as 10 min. I think this is a bug in the core.

71

Thanks @stefanbauer!

Activity Log: With 1.9.0 (update via Gladys) there is an option in the configuration „Resend presence every minute“ (default on, as before). If you turn it off, the integration only sends changes: The activity log remains clean, but the scene action „Check presence of users“ will no longer work for these devices.

0 → 10 Min.: You’re right, this is a bug in the core, specifically in the scene editor: The server accepts 0, but when you reopen the scene, the editor silently replaces 0 with 10, and on the next save, 10 remains. I’ll pass this on to the Gladys team, along with the location in the code.