tl;dr: It is a 1.9 binding which means it works in OH 1.8 and OH 2.0. The above code is running in OH 2.0 but should work in 1.8 unchanged.
I agree, it is confusing. We are in a state of transition right now but OH 2 is rapidly maturing to the point where it will soon become the default assumed version talked about.
In this particular case, there will never be an update of the core of OH 1.8 to version 1.9. However, most of the bindings and add-ons have continued development. These bindings and add-ons are referred to as version 1.9. You can (and probably should in some cases) run 1.9 version bindings in OH 1.8.3.
In OH 2 there is a new architecture and a new way for bindings and add-ons to work. There is also a compatibility layer which allows one to run older 1.x style bindings inside OH 2. As it stands right now as of this writing, there are more 1.9 bindings that are part of the official distribution than 2.0 bindings, including some really essential bindings like MQTT and HTTP. Though that is going to change soon.
In the Migration Tutorial I actually used an approach that lets one first swap out the core to OH 2 but remain on 1.9 version bindings. And then gradually transition to the 2.0 version of the bindings.
So in short, if it says version 1.9 it will work in 1.8.3 and 2.0.
So here are a few rules of thumb I would use to determine if something posted is applicable to OH 1.8.3 if the:
The problem with that is most of my sensors only report when there is a change. Furthermore the groupās state doesnāt change very frequently. Therefore there isnāt an event to keep rescheduling the timer. You could add a rule that triggers every few minutes to refresh the timer by sending an ON if the sensors are still on, but if you do that you may as well implement the timer in that rule.
In the end, you could use Present as the timer so long as ON keeps getting sent to it while you are present every <n minutes where n is the timer length. That isnāt the case with the code above.
I use a combo of sensors none of which am I particularly happy about their performance for detecting iPhones.
I use the Network binding to ping devices (work like a champ for Android).
Iāve recently implemented the hping3 sensor @ThomDietrich linked to which Iām finding works no better than Network. Iām not sure if I need to adjust the timing or something else but so far Iāve never seen the hping3 detect the device present when Network did not and visa versa. Of course, the hping3 may be making Network work better.
Iāve a Pi 3 running reelyActive. So far it it detects BTLE devices like a champ (my fitbit, wifeās Dexcom and Pebble watch) but it detects the iPhone and my Android very poorly. But this may be caused more because I canāt figure out which device is which so I might not have identified the IDs of the devices I care about. I do notice that every time someone walks by the house reelyActive picks them up. Iām going to watch it some more but this might be a secondary way to detect when someone comes to the door (package delivery). What would be great is if I could find some sort of way to map the BT address of a device, which I can discover on my own, with the reelyActive deviceID.
Iāve also three Pis and my āserverā (old laptop) each outfitted with BT and I run a custom script which does something similar to reelyActive, only at a more primitive level, to detect the phones. This works reasonably well though because it uses a sort of moving average to determine presence it isnāt super responsive. Sometimes it also gets stuck reporting a device as ON when it is no longer present,
Iāve not spent a lot of time trying to figure out the problems I have with each of these. Iāve recently had something major go wrong in my office which has really messed up my electronics in strange and inexplicable ways. My monitor died (probably a failed capacitor), the BT on my laptop server can no longer be found, I can no longer access port 443 on the laptop server despite there being no IP tables rules block that port and netstat clearly showing that nginx is listening on that port for all addresses. All my network gear had to be reset (thank goodness for dd-wrtās backup feature) and I had to remount all of my drives. I donāt know if it was a power surge or an EMP but needless to say, I currently have some bigger problems to figure out right now so Iāve all but disabled my presence detection.
Anyway, as for being on Windows, hping is available on Windows. It will probably require some powershell scripting to make it work but it is not impossible.
@rlkoshak Thanks for the mega tutorial, however i have a question, my phones (android, two different makes) keep being marked as ānot connectedā by the network binding, despite still being on wifi (and visible on my router as connected), they do then come back but they drop in and out all the time. Does my Thing file look like a valid use case or do i need to tweak something.
I had the same problem with Android phones running Android 6 and above. I think they stop responding to pings when in doze mode.
I use the arp-scan tool combined with the exec binding for detecting phones. For a Nexus 6p, Nexus 5x and Galaxy S5 this works perfectly and always detects the phones (I had to up the number of retries to get the Galaxy S5 to respond reliably)
Yes itās normal (from a technical stand point) but there are of course ways around that. @MikeJMajor refered to the following solution I suppose. Itās reported to be quite reliable between many devices, including Androids and iPhones in doze/deepsleep mode:
Iāve not done enough experiments to prove it, but I think hoping combined with Network binding might be a viable approach. I noticed when I was playing with it that periodically hpinging the iPhone made the Network Item linked to its ip work more reliably.
Also, if I remember correctly doesnāt the script first clear the arp table before doing the hping?
Based on this conversation, I decided to change my script to that from SeaSide, because it loops through multiple IPs. Tested this arvo, and it works; also, and yes, because of clearing the arp entry for the relevant IP. Nice.
Also adopted the MQTT publish approach, as this is what I will be using (Architecturally) whenever possible.
From a rights perspective I had to use sudo in front of the arp entry deletion, and add openhab to the sudoers without password.
No network binding used for this.
So basically, the shell script is triggered by a rule.
The script publishes to mosquitto topic;
OH subscribes to mosquitto topic
@Max_G
Glad it could help someone. I prefer to not invoke the polling to see if a device is available from within openhab, since
I run it every two minutes for several devices, IMO itās better suited to be run outside openhab in a crond-job or similar.
You donāt have to give openhab permissions to all commands in the sudoers table you can add
username ALL=(ALL) NOPASSWD: /sbin/ip
to allow allow username to be able to execute ip (for flushing that is). Iām sure you are aware of this, but just writing it since it seems a lot of people allow openhab to execute just about anything.
Just because Iām curious: With the two iPhones in my house, as soon as I integrate the arp flush, the script doesnāt work reliable. Without this line, itās pretty solid and only misses a beat from time to time.
When you guys say it works for you, do you also use iPhones or only Android?
