I also ran into the issue when I turned on my US-24-250 switch (it was off for a while due to a renovation project). Installing this version fixed it. If you need examples of JSON, I can share some with you (securely).
New binding installed in both locations. Your new filtering mechanism (entering the site in the wireless client config) is working nicely. Thanks!!!
Trying out version 2.1.0.201704101808 - after I link the essid channel to an item, I start getting the following errors (I persist everything to an InfluxDB). Once that happens I have difficulty adding new (PaperUI complains about 500 errors from the web server) until I delete the item and the link.
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: [ERROR] [org.influxdb.impl.BatchProcessor] - Batch could not be sent. Data will be lost
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: java.lang.RuntimeException: {"error":"partial write:\nunable to parse 'JeffsPixelXL_WirelessNetwork 1491871080002000000': invalid field format"}
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.InfluxDBErrorHandler.handleError(InfluxDBErrorHandler.java:19)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at retrofit.RestAdapter$RestHandler.invoke(RestAdapter.java:242)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.$Proxy124.writePoints(Unknown Source)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.InfluxDBImpl.write(InfluxDBImpl.java:151)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.BatchProcessor.write(BatchProcessor.java:171)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at org.influxdb.impl.BatchProcessor$1.run(BatchProcessor.java:144)[216:org.openhab.persistence.influxdb:1.10.0.201702140757]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
Apr 10 19:38:00 svr05.ocjtech.us openhab[20935]: at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Checking if devices are online is useful, although you could do that with the network binding.
But looking at the /STA JSON API, there is also a ālast seenā and āuptimeā properties, which give history, something the network binding canāt do. And you can see on which port of the switch it is connected.
I wonder if there are other APIās because the controller knows a lot more about the APās, clients and switches (I donāt have a Unifi router/gateway).
You can always watch the XHR calls in the browser while accessing the UI - itās what I do. If you see anything interesting, Iām always open to suggestions.
As far as wired support goes, I will work on it when I can, but I really canāt think of a use case from an āautomationā perspective. Sure thereās a case for persistence / monitoring, but there are far better tools out there to solve that problem.
The biggest reason I wanted to develop this binding was for monitoring my phone via wireless associations. This binding gives me a pretty reliable way to tell if my wife or I are at home ā¦ well at least our phones
One use of the properties you mentioned would be shortening / overriding the time it takes for the controller to report a client as offline. It can be anywhere from 5-10 minutes before the controller removes a client and they appear as OFFLINE. Maybe an additional ātimeoutā parameter on the client configuration could be use where if not seen in last X minutes, report as OFFLINE.
Iām having an issue with the periodic scanning stopping. If I reboot the box, or restart OH, I can see from the unifi.log that there is scanning taking place every so may seconds. The problem is that after a few hours, the scanning stops, although if I go into Habmin and manually refresh one of the things, it populates the unifi.log file, but the periodic scans donāt start again. I restarted the box yesterday around 11:30am and it worked fine until about 6:30pm when it stopped scanning. I did a manual refresh on a few things at 9:30pm last night and as of 10:30am this morning those manual scans are still the last entries in the unifi.log.
@roryd no idea - my instance has been chugging along just fine.
I added some more logging and exception handling so please update and try again. Once it stops refreshing, please send me the log via PM (just as you did before).
@mgbowman If thereās an unhandled exception during a scheduled job, the job will be canceled and will not run again until the binding (or OH) is restarted. This all happens silently, so thereās no log file entry that shows what happened. Wrapping the scheduled job run method with a RuntimeException try/catch block is what Iāve seen done in other bindings (including my own bindings).
Thereās some discussion here, a little over half way down the page.
Edit: Nevermind, I see you already wrapped it with try/catch.
Yeah, seems like the most sane solution to help with debugging.
In the meantime, Iāve narrowed down @rorydās issue but itās the strangest thing. One of his phones somehow was being reported as a wired client from his controller. Looks like Iām going to have to add an extra check to make sure Iām dealing with wireless clients only (until I can add proper support for wired clients).
I had actually spotted that in the Unifi topology map but never thought too much about it.
I looked at the sw_mac in the two sections you PMād me, and in the first, the iPhone was connected to an AP which was wired directly into a switch in the attic. In the second section, the iPhone was connected to an AP in the kitchen connected to a PoE switch in the kitchen connected to a Devolo Powerline Ethernet adapter in the kitchen, which then connected to another Devolo unit in the attic which connects to the switch in the attic. I wonder if the powerline adapters are confusing the āis_wiredā calculation? I updated the Cloud Key and the APs to the latest firmware (3.7.51.6230) last night, so Iāll keep an eye on it and see if that makes any difference.
I want to run a cable directly from the kitchen to the attic, but I need planning permission
Yeah, me too. It was driving me nuts trying to figure out why my scheduled job just silently stopped running.
BTW, yesterday both my unifi binding instances stopped running their scheduled job. Since they both point to the same Unifi controller, Iām assuming it was the same root cause. I have since installed your latest jar, which has the try/catch block. Iāll post something if I see it happen again.
The only thing out of the ordinary yesterday is that I powered off the Unifi switch, which also took down one AC-LR that was getting PoE from the switch. (Once all the cables are run to the rack, all my APs will get PoE from the switch. )
The switch is still off, and I wonāt be in that location until next week. When Iām there Iāll power on/off the switch to see if it causes the Unifi controller to report something you might not expect.
Edit: I did see this in one of the logs (for the site thatās remote to the Unifi controller). I seem to recall that I had come back into the house from being away for about an hour.
In the meantime, Iāve reworked the binding data model to better distinguish between wired vs. wireless clients. Thereās still no support for wired clients, however it should solve @rorydās issue.
The only downside is, if the controller misrepresents a wireless client as wired, the easiest thing to do is to treat the wireless client as non-existent. This means itāll appear OFF and all the other channels will be UnDef.
@roryd please update to the latest version and report back.
I discovered that I can force this to happen. If I click āReconnectā on a wireless client in the UniFi console, and that client is connected to the access point in the kitchen (the one using the Devolo Ethernet over Powerline units), it reappears as a wired client connected to the port in the switch where the Devolo unit is connected. After a minute or so, and/or a refresh of the topology, the correct wireless connection shows up.
Hi, any change this could change the POE state of a port on a UniFi POE switch? I have a few devices (like Raspberry Pi with touch screens etc) that Iād like to power off for example when I leave and come back on again when I come home.
@jmccoy555 Currently the binding does not support this. However, I just took a quick look at the API and theoretically it is possible.
Unfortunately I only have a US-8 with PoE passthrough so Iām not really going to be able to implement support beyond this model. Of course Iām always open to donations for a proper UniFi switch to fully implement PoE support
So I suspect the answer is no, but I was hoping to use this with my Unifi EdgeMax to determine presence of phones (I use a Eero wireless mesh network, not the Unifi APās)?
Wow, interesting binding. I could use the same for presence detection. However, my Ubiquiti controller is on a separate network where I do not have access to from my openHAB . So I first have to think about how to incorporate this into my network topology.
If you really want presence detection on your openHAB network (I assume at home), I highly recommend running an instance of the controller there. This way - regardless of Internet connectivity - your presence detection will work as itās all local.