Wifi client connection status as triggers?

  • Platform information:

    • Hardware: raspberry pi 4/4gb RAM/240gb ssd@usb3 external sata-case
    • OS: raspbian
    • Java Runtime Environment: unknown
    • openHAB version: 2,5 i belive
  • Issue of the topic: i wish to use a list of vip wifi users, that when any of them connects, my hallway light turns on.
    Also, if none of the vip clients are connected, turn off all my lights (exept the aquarium, whitch is in timer) are turned off.

  • Please post configurations (if applicable): Philips hue gateway, Logitech harmony hub

    • Items configuration related to the issue : not an issue, just want to know if its doable and if so, some hints to help me do it. :slight_smile:
    • Sitemap configuration related to the issue
    • Rules code related to the issue
    • Services configuration related to the issue
  • If logs where generated please post these here using code fences:

  • non-openhab-related:
    My router is running a open-source linux system (currently dd-wrt) that accepts shellscripts and so on. It is possible to install custom sw onty my router (apt-get and so on), but i also have my openhab-running raspberry that could easily manage the computations and send commands to my philips hue-system.

Now my idea is that its probably easiest (and more secure) to have the router poll its own wifi client list.
Im thinking a periodic shellscript compares a list of predetermined client id’s with the list of last wifi-client-list.
And if a vip-name is found, open a url link that targets a empty .htm-doc residing on the raspberry.
Else if no current client matches the vip-list, open a separate url, that the raspberry then takes as a command to update the status of a openhab virtual item, turning its state off and on, depending on witch url was used.
For example: “http::/rasbpi.local/cmd/light_hallway/on.htm”
“http::/rasbpi.local/cmd/light_all/off.htm”

If there is a simpler method of getting the desired end-result, please tell me! :slight_smile:
Someone on a different forum suggested that there might already be integrations in the openHab system, but im having some unrelated issues and have yet to take a closer look (broke my hdmi-adapter some time ago and it seems to have stopped accepting incomming ssh connection).

Any and all hints, ideas and solutions are welcome are welcome as even though im willing to learn, my linux skills are currently very limited…
(Anything NOT related to my “unrelated problem” please, i"ll sort that with new adapter.:slight_smile: )

And yes, i realise that im asking for MQTT, but unfortunately, the dependencies require several hundred megabytes on a device that has 64mb…

I may have misunderstood your goal, but to me it sounds like the best approach would be to do the following:

  • use the “network”-binding to track (*) selected Wi-Fi devices (network clients)
  • use a “normal” rule to turn on or off the lights depending on what clients that are present

(*) by tracking a Wi-Fi device I mean decide whether it is currently connected to the network or not.

1 Like

Off the top of my head there are a couple of things to consider.

What kind of devices are are talking about connecting? If you vip’s are primarily using mobile devices then getting a consistent id on these devices is can be difficult. Most mobile devices these days that I’m familiar with spoof random MAC addresses when they connect. So you’ll have to disable that feature if you haven’t already on each device (on many devices this can be done on a network by network basis).

If your devices connect in a way that is easy to find, static ip or broadcast hostname (if I recall, dd-wrt makes it fairly easy to set custom hostnames per device) then there are a couple of good ways of achieving this from within OH.

  1. KjetilA’s recommendation of the network binding is probably the most common way of doing this. Each device can have an associated item that will switch on when connected.
  2. dd-wrt should also support snmp. The snmp binding is a slightly more advanced approach than the network binding, but will give you many other options as well. You can also have items for each device this way.

If you put all these items into a group with the correct aggregate function, then that group will be on if any of the items are connected and off otherwise and your lights can trigger off of changes in the group status.

If neither of these more internal methods work for you, you can use scripting on the router, but at that point I would skip the htm-doc portion which seems overly complicated and just make calls to the OH api directly.

The tl;dr is with modern phones you can’t achieve this without making changes to the VIP phone’s settings.

That can be turned off, at least on Android, on an SSID by SSID basis. So if OP can have the VIPs change that setting then there is a work around for that problem at least. If not OP is kind of out of luck because there will be no way to tell that a given device is one of the VIPs.

That can be done, but the “client name” is going to be the MAC address of the device. From that you can configure dd-wrt to serve out the same IP address to that device every time which will make the IP address be another “client name” you can use. Once you have that, you can use something as simple as the Network Binding to sniff the DHCP requests or just ping the IP address to see when the device is present or not.

That is essentially how I do this for presence detection. Our phones are configured to not spoof their mac address when connected to my home SSID. My router (pfSense) serves out the same IP address to each phone (which it identifies by MAC address) every time. openHAB uses arping to ping the phones and see if they are still online. I run in Docker and don’t want to run as root so dhcp sniffing isn’t an option for me.

Another approach, if these are Android phones, is to have a Tasker app publish a message to openHAB when ever it connects to the given SSID. This can be effective as it doesn’t require the changes to the phone settings, but it does require installation of an app on these phones.

This is all very much overly complicated. openHAB provides a REST API. A REST API consists of web calls. So you can have what ever just change the Item’s state from ON to OFF directly. There is no need to set up a separate server to do that. But again, the root problem is identifying the VIP’s device which will require changes to their device. After you can identify the device the problem becomes really simple and doesn’t require much more than using the Network binding.

If you did want to put this all on your dd-wrt router, you don’t need MQTT. You can use curl to update or command the Items directly. See DD-WRT Presence Detection with ARP for openHAB, Check presence based on OpenWRT WiFi clients on-line and many more examples which you should have found by searching “dd-wrt”.

Have a look at arpalert as long as you can trust the MAC addresses are not spoofed. It can trigger an action in a script.
In case you can’t identify your VIPs by their phone’s MAC address you could use a page where they need to authenticate before getting access to your wifi network. Once they are authenticated the IP address can be used to track the current session.

Just a note on using the network binding, if you put the presence switches for all of the phones into an OR group, you can then run your rule based on the group rather than having to include every phone in the rule trigger.

You’ll want to set up conditions for the rule to run, or else you could end up with false positives that trigger your rules unexpectedly. You may have already considered this, but I’ll mention it for the sake of future readers.

I have a string item that indicates the current system status, with modes such as Home, Away, Sleep, etc. Most of my rules check the system status, and some of those rules will trigger a change in status. So in your scenario:

  1. Status is set to “Away”
  2. Phone connects to WiFi and triggers rule to update status to “Home”
  3. Status change from “Away” to “Home” triggers another rule that turns on the hallway lights.

And then you have this:

  1. Status is set to “Home”
  2. You reboot your phone, which causes it to disconnect and reconnect to your WiFi
  3. Since the status is set to “Home”, openHAB ignores the disconnect/reconnect

A system-status condition will prevent a lot of grief down the road.

Another approach one can use is to debounce the Items. I wrote a debounce library in fact that will debounce the state of the Presence Items when they turn OFF but not when they turn ON. So I have to be away for a couple of minutes before I’ll actually be considered away. It’s all configurable and configured with Item metadata. This let me eliminate my special purpose presence detection rules entirely.

It does require creation of a proxy Item though. There has to be somewhere to debounce the state to. Debounce is also useful in other cases where one might have a buggy sensor. I’ve a reed sensor that goes nuts occasionally when it gets cold. I use this same library to only count the door as open if it remains open for half a second. It works quite nicely.

1 Like

The word “debounce” makes me go cross-eyed whenever I read it. Even though I understand what it is, I instinctively want to think, “it’s the opposite of bounce”. And boom, cross-eyed.

So that was a lot of fun reading it no less than six times in your post, Rich. I won’t be able to see straight until tomorrow. :wink:

It kind of is. Think about a basket ball. If it has air in it, it will bounce. Drain the air out of it and it just hits the ground with a thud. This rule takes the air out of the ball for you. :wink:

1 Like

I will mentally convert “debounce” to “splat” to invoke the imagery of a water balloon.

Another approach one can use is to splat the Items. I wrote a splat library in fact that will splat the state of the Presence Items when they turn OFF but not when they turn ON.

Hmm, I’m not sure that’s any better. Maybe “stick”, as in “stick the landing”.

2 Likes