Hmm, well I have seen OH hold on to deployed JARs sometimes. I always shut down OH, delete the old JAR, copy the new JAR in place, then start OH back up. If you turn up the log level to TRACE you should see some new log messages like these showing it comparing addresses of the interfaces.
2020-12-31 03:08:08.199 [TRACE] [lighting.internal.utils.NetworkUtils] - Comparing ip [xxx.xxx.xxx.89] to hostaddress [fe80:0:0:0:xxxx:xxxx:xxxx:xxxx%xxxxxxx]
2020-12-31 03:08:08.199 [TRACE] [lighting.internal.utils.NetworkUtils] - Comparing ip [xxx.xxx.xxx.89] to hostaddress [xxx.xxx.xxx.89]
2020-12-31 03:08:08.199 [TRACE] [lighting.internal.utils.NetworkUtils] - Match found.
2020-12-31 03:08:08.200 [DEBUG] [lighting.internal.utils.NetworkUtils] - Returning MAC address [080027XXXXXX]
2020-12-31 03:08:08.200 [INFO ] [rnal.handler.WizLightingMediatorImpl] - MAC Address of OpenHab device is 080027XXXXXX.
I didn’t even realize that version number was in there, so I haven’t been updating it. But I will next time.
I have some Wiz plugs here and they show up on discovery as White wiz bulbs and have all the standard bulb controls (dimmer, etc) instead of only the power switch, also the power switch doesn’t work. Happy to have a look if that helps - how would I capture the required elements from the plug?
Hi Josh, I had to delete my CACHE folder. Now the new WizLighting JAR works and auto discovered all my Bulbs! Great Work I can also see your code work out (in TRACE mode) the correct NIC.
@ottawahacker unfortunately the binding does not even attempt to recognize plugs through discovery, it just treats anything it doesn’t recognize as a color bulb. However, the power switch (state channel) should be working even in that case. You might try adding it in manually as a plug, but literally all that does behind the scenes is restrict which of the channels are available.
If you could set the log level to TRACE for this binding (org.openhab.binding.wizlighting) and get me the moduleName for the plug, it will be in a JSON response and look like something like:
“moduleName”: “ESP01_SHRGB1C_31”
With that I can probably make it auto-discover them correctly.
Edit: Realized you said it was detected as a white bulb and looked again, the default is color but it then switches to a Dimmable White Bulb if the module name doesn’t contain “RGB”.
With the module name, getting the plug to detect and work will (hopefully) be easy. No one ever has had a plug before, but I put the skeleton of what I expected the plug commands to be in the code.
Also I can confirm that setting the item manually as wiz plug works. Status (on/off) was recognized properly and switching it on and off from openhab works correctly.
To note, the power switch state with the plug was not working when recognized as dimmable white bulb.
12:00:39.635 [DEBUG] [rnal.utils.WizLightingPacketConverter] - Incoming packet from 10.0.0.115 to convert → {“method”:“getSystemConfig”,“id”:1,“env”:“pro”,“result”:{“mac”:“a8bb50b45ba9”,“homeId”:1248073,“roomId”:3465707,“moduleName”:“ESP10_SOCKET_06”,“fwVersion”:“1.21.0”,“groupId”:0,“drvConf”:[20,2],“ewf”:[255,0,255,255,0,0,0],“ewfHex”:“ff00ffff000000”,“ping”:0}}
Edit: Small suggestion on the discovery - I would extend the timeout to 30 seconds because I had to do 3 or 4 manual scans until the system got some results.
Thanks, that’s a convenient naming pattern, looks like I can check for “SOCKET” in the module name to detect plugs and that seems pretty safe to add that based on the bulb module names. I’ve added that and built a new version. (Also updated the binding version to v0.03.03.) @ottawahacker please test this out with your plugs.
I looked through the code for the state channel and don’t see anything that should behave differently based on the type of thing, so not sure what’s different about it being detected as a plug. Maybe @SRGDamiano has some idea? In any case, I think this will detect the plug correctly now.
On the discovery timeout, haven’t changed that yet. It looks like it is currently set to 2 seconds which is really small it seems to me. @SRGDamiano any suggestions here, I’m not sure of possible side effects to increasing this.
Edit: Never mind on the timeout, I realize now why it doesn’t matter. The discovery sends out a broadcast message on the network then immediately shuts down. It uses the passive background discovery to handle the responses when they come in from the devices. So I don’t suspect increasing this time will help with having to run discovery multiple times to get all the devices.
@frejos - There shouldn’t be anything different (in the code) in the commands for the state of a plug vs a light. In my house I only have the full color bulbs and wrote everything else up to use just a subset of those commands. Based on a few other people testing with tunable whites, that seemed to work out.
Yes, the timeout shouldn’t make a difference in the discovery. I’m not sure why the bulb/plug wouldn’t respond to the discovery request the first time.
Yes! I can confirm the plug got detected correctly as plug. Great job!!
I think the reason is that the wifi connection to all my wiz bulbs seems quite fragile which is causing the discovery to fail frequently. Even on the app, I might have to wait ~10sec to get a connection sometimes. And that is with all the bulbs & the plug.
I found the biggest issue with the Bulbs is they hang on to the first WAP they connect to. I’ve a pretty extensive Unifi based setup and when I upgrade the firmware on the WAP, the bulbs can end up connecting to a WAP on the other side of the house and the only way to “force” them to the close WAP is to power them OFF then ON.
I had the same issue for a couple of tasmotas and Google Home speakers and figured out that in OpenWrt you can blacklist a MAC address from connecting to it. That fixed it. You might want to try OpenWrt if it’s available for your router.
Has there been any investigation on the Thing File issues a few of us are having? I bit the bullet and updated to OpenHAB 3 today as the Echo Dot binding issues with 2.5.1… And my understanding is that OpenHAB3 is either file configs or the new configs… I have everything else in file configs
So here’s my error in the openhab.log:
2021-02-03 02:13:16.558 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key wizlighting:wizDimmableBulb:HallwayLight in ManagedThingProvider, because it does not exists.
My things file (one item, personal details redacted):
I’m sorry, I’ve hardly used the things/items files so I never really tested them. You should not include the “homeId” parameter in your file. I think some of the very first versions might have used it, but the current one does not. You can see if removing it makes a difference.
removing it didn’t make a difference. Things files still not working. Though I manually added my “things” and use an txt files for Items, Rules and Sitemaps, and those work.
now I’m working on sending the color changes from the rules (So I can simplify my Alexa routines)
I gave the latest jar I could find for 2.5 a shot → org.openhab.binding.wizlighting-2.5.7-SNAPSHOT_20200626.jar
It installs just fine and I was able to add the Thing and the Channels. Yet I’m facing an issue with the “IP of OpenHab device”. My OH installation runs in Docker so the internal 172.xx.xx.xx address is picked up which is wrong. To access my OH instance a 192.168.xx.xx address is used. Is there a way to overwrite the OH IP? Also the related MAC Address is wrong.
I decided to try out some Wiz bulbs because I saw this thread, simple dimmable Warm White ones. Just downloaded v0.03.03 JAR, put it in $OPENHAB_HOME/addons, restarted OH3, and bingo I had a Wiz light in my Inbox!
Might buy other Wiz lights or other Wiz devices in the future if we like the performance of these initial ones, because the setup was super easy in their app and then into OpenHAB.
For the record my lights are on firmware 1.22.0 . I think it is good they update it because of security patches. Last thing I want is my lights becoming part of a botnet to produce DDOS traffic. I just hope or expect they don’t break the API again.
You can get the IP and MAC of each bulb in the WiZ app, at least the Android version.
go to your home/room and click on the light in question
at the bottom, click on the gear to the right of the bulb’s current mode, this opens the light setting page
on the light setting page, click on the model name (ie, A19) this takes you to another page with the firmware version, the MAC, IP, RSSI, and a few other details.
I have no idea if being in a container would affect the communication with the bulbs. I’m pretty clueless about containers. The communication is all over UDP.
I can also see your code work out (in TRACE mode) the correct NIC.
