Attached[trace.log|attachment] (17.6 KB) shows the parsing errors + from startup of OpenHAB with attempts to add the bulb both Auto and manually.
Thanks
Nathan
trace.log (17.6 KB)
FYI…if you look at the Log in Notepad++ you can see all the NUL being returned from the Incoming packet.
Shoot, I must have posted the older version again or something. I added code to binding to crop off the nulls at the end (and post a TRACE that it was doing so), but you’re still getting the nulls and no message. Give me a few minutes and I’ll repost.
I think it is me. I don’t think I put the right version it. I’ll retest in a bit…
Ok, just for good measure I rebuilt it and added a fat print-out stating the binding version number when the binding activates. If you don’t see something saying 0.02.11, something’s up. At minimum you should restart the service when updating the binding. Clearing the cache probably wouldn’t hurt either.
Thanks - I’ll test the new version today and get some logs back… but the good news is the Last Version does work!
- Added to Inbox automatically (but as a Colour Bulb not Dimmable one colour)
- Power On/Off works
- Brightness works
- Colour Tempurature works
Nice! Let me know of any specific things you want tested esp around the detection of the correct bulb type… but well done!!!
For anyone else who might be trying to update from an older version, the binding should automatically “rebuild” all of your things as the newest version so you shouldn’t need to delete and re-create everything to update them.
I got really sick of the delete-and-recreate step with my own bulbs as I was testing versions and modifying channels so I added code to call the thing builder to completely “build” exactly the same as the old thing (but attuned to the new binding) anytime the binding version property of the thing didn’t match that of the binding itself.
Oops, sorry, there is a note in the read-me about that. Yes, the discovery service creates everything as “full color with tunable white” and creates all of the corresponding channels. For anything else, you have to create it manually. If you do manually create one a “dimmable white” bulb, you should only get appropriate channels for that (ie, no RGB) but it won’t happen via discovery.
And… that’s because I only own the full color bulbs so I had no idea what moduleName anything else would return. Both the BR30 and A19 full color bulbs reply “ESP01_SHRGB1C_31”. It looks like your model name was “ESP56_SHTW3_01”. Are yours really single color or are they the tunable white?
You can see the model name quickly in the thing properties if you don’t want to dig through trace level logs.
The bulb I’m playing with is reported as “ESP56_SHTW3_01”. Here is a link to it:
https://www.wizconnected.com/en-GB/consumer/products/st64-filament-whites/
Those are tunable white. At least in the US, WiZ also sells some that are really single color: https://www.wizconnected.com/en-US/consumer/products/a19-dimmable-warm-white-us/
I don’t think there’s much hope of parsing the meaning of the whole model name and I suspect it will vary by exactly the revision, but I can add a text filter looking for the characters “TW” or “RGB” and use that accordingly.
I manually added it as a “Tunable Build” and as you say the RGB controls then don’t appear. Controls all work very well so far.
Under the controls is a set of “Light Mode” of which the options avaiable seem to be for both the Colour and Tunable White bulbs, hence some error out in the logs (the Bulb just ignores the ones it can not set). It’s not a big deal but FYI here are then Light Modes that work / do not work on this build:
- Works: Cozy White, Wakeup, Bed Time, Warm White, Daylight, Cool White, Night Light, Focus, Relax, TV Time, Candlelight, Golden White, Pulse, Steampunk
- Does Not Work: Ocean, Romance, Sunset, Party, Fireplace, Forest, Pastel Colours, True Colors, Plant Growth, Spring, Summer, Fall, Deep Dive, Jungle, Mojito, Club Christmas, Halloween
FYI - Pulse is pretty interesting 
Sounds like a good plan.
My kids love “party” mode. I like cozy and fireplace.
Here is the only “odd” thing I’ve found so far, the “Color Temp” slider keeps defaulting back to 50%, but it does not actually change the bulb in any way only in the UI and Logs. It seems every minute or so this set shows up:
2020-06-10 11:10:42.493 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_lastUpdate changed from 2020-06-10T11:09:22.318+1000 to 2020-06-10T11:10:42.493+1000
2020-06-10 11:10:42.494 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 50 to 0
2020-06-10 11:10:42.494 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 0 to 50
2020-06-10 11:12:02.633 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_lastUpdate changed from 2020-06-10T11:10:42.493+1000 to 2020-06-10T11:12:02.632+1000
2020-06-10 11:12:02.633 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 50 to 0
2020-06-10 11:12:02.633 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 0 to 50
2020-06-10 11:13:22.785 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_lastUpdate changed from 2020-06-10T11:12:02.632+1000 to 2020-06-10T11:13:22.784+1000
2020-06-10 11:13:22.785 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 50 to 0
2020-06-10 11:13:22.785 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 0 to 50
2020-06-10 11:14:42.949 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_lastUpdate changed from 2020-06-10T11:13:22.784+1000 to 2020-06-10T11:14:42.949+1000
2020-06-10 11:14:42.950 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 50 to 0
2020-06-10 11:14:42.950 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 0 to 50
2020-06-10 11:15:42.968 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_lastUpdate changed from 2020-06-10T11:14:42.949+1000 to 2020-06-10T11:15:42.967+1000
2020-06-10 11:15:42.968 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 50 to 0
2020-06-10 11:15:42.968 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 0 to 50
2020-06-10 11:16:44.769 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_lastUpdate changed from 2020-06-10T11:15:42.967+1000 to 2020-06-10T11:16:44.769+1000
2020-06-10 11:16:44.769 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 50 to 0
2020-06-10 11:16:44.769 [vent.ItemStateChangedEvent] - wizlighting_wizTunableBulb_c79efdec_temperature changed from 0 to 50I’m now going to grab a few of these for around the house. I like the “old fashioned” amber look to the light source (for dinning / lounge room etc) rather than the RGB Aeotec’s I have. Plus, they are much cheaper and I can get them in both BC and ES to suit the lamps I already have. 
Thanks for all your work on this. I’d love to contibute something to your Beer/Wine/Coffee etc fund!
If I physically turn the light OFF then ON again the binding sees it as a new light and adds it back to the Inbox.
Well, that’s not supposed to happen. It’s probably something to do with the discovery trying to call it a color light. Are you sure you have the settings for discovery (for openhab in general) set to ignore identical results?
I’ve not changed any default settings in OH in regards to discovery. My impression is:
- I add a light to the network and it is auto found as a Colour Bulb
- I delete this and add Manually as a TW
- If I then power off/on the bulb it is then auto found as a Colour Bulb.
I did not keep track of the openHAB serviceID’s that were being created to see if it is being given a new one or not… but I do have some bulbs I’ve not yet added so I can test if you want but I’d prefer to wait till the binding has the ability to distinguish between Colour and TW.
So the 4 Bulbs I’ve added so far (manually) all reappeared in the inbox, using their original openHAB serviceID’s (which are different to those from when I add them manually).