LightwaveRF - New LightwaveRF Binding

I think i have found the issue.
ill get rid of it shortly, was this a stress test only… as i don’t think you really want to set it that low… 20-40 is ideal

Yes, I do some testing at work, so attempt to break things deliberately :slight_smile:

Ok, I’ve done some investigation on dimSetup, as predicted, it’s related to Calibration.

When already calibrated, it seems to have a value of 113868800

You seem to be able to set this to any value above 0 and it doesn’t seem to do anything

If you set it to 0, then it force a recalibration.

I’m not sure how you would code this, I assume maybe a fake switch that sets it to 0 if turned on?

EDIT: doesn’t always seem to be 113868800, one I’ve not played with is 136839168, another is 134955008, I assume it’s something to do with the result of the calibration, but changing it manually seems to have no impact on the dimmability of the bulbs

bulbSetup is a number based upon the settings in the app for the switch, from what I can tell it’s loosely calculated on the following:

  • Total number of lamps controlled by switch
  • The wattage of each lamp controlled by the switch

image

Not sure it’s of much use in OpenHAB at present?

EDIT: forgot to add, the app states these figures ‘help us calibrate the energy monitoring capabilities of this device’

Running 1.0.8 anyone else have an issue where if you change the dimlevel the slider returns to 100 but the light is at the new selected level?

I’m having issues adjusting Brightness on sockets led, also running 1.0.8, slider returns to 100 and nothing changes

Can I ask a very basic question? It looks as if this new binding uses the lightwaverf cloud server to do all the heavy lifting, so if I only want to use my Gen1 hub as a local controller then is this new binding overkill? It seems the original binding is exactly what I want, but as I’m trying to only use OH2 bindings then that’s not an option for me. Does anyone have a view on this?

(I do have a stop-gap solution using netcat commands that seems to work for me, but it’s a hard-coded bodge!)

This indeed uses the cloud servers as any gen2 stuff is only controllable this way. Although integration is available for gen1 equipment using the cloud.

You would have to carry on using the v1 binding if it’s just gen1 equipment you have and want local control.

@BenDWire
Could you do me a favour.
Add the binding
Add your account
Discover devices and add them.
Go to each device in paperui (different types) and send me what it lists under properties
I’m only concerned for gen1 hub and everything else gen1 not (single socket/energy monitor/thermostat)

I can’t promise anything but I’ll take a look at a possible gen1/gen2 split time keep gen1 hubs local

Thanks Dave - I suspected that was the case. My experience with the hardware has been less than favourable anyway, with a few sockets going faulty despite having very little load applied, so I may well cut my losses and switch to a WiFi solution instead.

I’ve had my gen2 sockets in for about 2 years now (1st batch), and touch wood I’ve not had a blip yet

Sorry - our replies crossed!
My biggest problem is that I use a PiHole to block all my local IoT stuff from leaking out into the cloud. I did disable it and try to use the binding with no success. I’ll give it another go and report back.

OK, so I deleted my configuration files from my previous attempts (.things & .items) and added the 1.0.8 binding once again. I added my (correct!) account details but ended up with UNINITIALIZED - HANDLER_INITIALIZING_ERROR for the LightwaveRF Account Thing. According to the log, I am “connected to lightwave” but when the List Generation was started it threw an error while calling ThingHandler.initialise(). Debug log shown below.

12:06:29.037 [WARN ] [g.lightwaverf.internal.UpdateListener] - Connected to lightwave
12:06:29.044 [DEBUG] [erf.internal.handler.LWAccountHandler] - Started List Generation
12:06:29.350 [ERROR] [rnal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.lightwaverf.internal.handler.LWAccountHandler@8fac75': null
java.lang.NullPointerException: null
	at org.openhab.binding.lightwaverf.internal.handler.LWAccountHandler.createLists(LWAccountHandler.java:112) ~[?:?]
	at org.openhab.binding.lightwaverf.internal.handler.LWAccountHandler.initialize(LWAccountHandler.java:83) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_222]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_222]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
12:06:29.371 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lightwaverf:lightwaverfaccount:c3e53c09' changed from INITIALIZING to UNINITIALIZED (HANDLER_INITIALIZING_ERROR)
12:06:29.372 [ERROR] [.core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'lightwaverf:lightwaverfaccount:c3e53c09': null
java.lang.NullPointerException: null
	at org.openhab.binding.lightwaverf.internal.handler.LWAccountHandler.createLists(LWAccountHandler.java:112) ~[?:?]
	at org.openhab.binding.lightwaverf.internal.handler.LWAccountHandler.initialize(LWAccountHandler.java:83) ~[?:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_222]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_222]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

I ought to add that my Gen1 hub firmware version is U2.94D, just in case that matters, and I’m running OpenHAB 2.5.1

I have just uploaded a new version to Git.
Its a major change on how the polling is carried out.

@BenDWire should fix your issue.

You can set the brightness either by going to the outer edge on Colorpicker or reducing the brightness using HSB sliders. (lightwave restrictions here so temperature on colourpicker doesnt do anything)

This is now fixed

New Binding Version Available - Version 1.1.1

Various bug Fixes.

Account Parameter: electricityCost
set this to a whole number (pence) in order to use the new channels:
energyCost
powerCost

Channel energyReset
use this to reset the current energy usage, IE in rules to reset every month after logging a historical value

Channel voltageReset (Use with caution)
Occasionally the lightwave value is messed up and the only way to reset is to remove and readd the device in the app. This allows you to reset this value.
To use:
Turn the socket off
Flick the reset switch on then off
Power cycle the device using the reset channel switch.
The voltage should now be reset.

UPDATE
Version 1.1.2 added
Fixed update bug for linkplus

I had a go with 1.1.1 and the logs showed the account connected but never got anything back:

2020-02-21 16:11:30.399 [DEBUG] [rf.internal.handler.LWAccountHandler] - Checking Lightwave connection
2020-02-21 16:11:30.401 [DEBUG] [rf.internal.handler.LWAccountHandler] - Connection to Lightwave in tact
2020-02-21 16:11:34.302 [DEBUG] [rf.internal.handler.LWAccountHandler] - Initiate Polling
2020-02-21 16:11:34.304 [WARN ] [rf.internal.handler.LWAccountHandler] - Channel List For Updating Is Empty, rescheduling
2020-02-21 16:11:35.771 [DEBUG] [rf.internal.handler.LWAccountHandler] - Initiate Polling
2020-02-21 16:11:35.774 [WARN ] [rf.internal.handler.LWAccountHandler] - Channel List For Updating Is Empty, rescheduling

Then I tried 1.1.2 and the account is stuck on Initializing, and is throwing many more errors:

2020-02-21 17:12:59.741 [DEBUG] [rf.internal.handler.LWAccountHandler] - Initializing Lightwave account handler.
2020-02-21 17:12:59.755 [WARN ] [.lightwaverf.internal.UpdateListener] - Start Lightwave Login Process
2020-02-21 17:12:59.758 [WARN ] [.lightwaverf.internal.UpdateListener] - Get new token
2020-02-21 17:12:59.707 [hingStatusInfoChangedEvent] - 'lightwaverf:lightwaverfaccount:9243d05c' changed from UNINITIALIZED to INITIALIZING
2020-02-21 17:13:00.686 [DEBUG] [.lightwaverf.internal.UpdateListener] - token: <redacted>
2020-02-21 17:13:00.689 [WARN ] [.lightwaverf.internal.UpdateListener] - Connected to lightwave
2020-02-21 17:13:06.862 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at org.openhab.binding.lightwaverf.internal.handler.LWAccountHandler.getDevices(LWAccountHandler.java:152) ~[?:?]
	at org.openhab.binding.lightwaverf.internal.handler.LWAccountHandler.initialConnect(LWAccountHandler.java:114) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_222]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_222]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_222]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
2020-02-21 17:14:00.698 [DEBUG] [rf.internal.handler.LWAccountHandler] - Start periodic connection check
2020-02-21 17:14:00.706 [DEBUG] [rf.internal.handler.LWAccountHandler] - Checking Lightwave connection
2020-02-21 17:14:00.712 [DEBUG] [rf.internal.handler.LWAccountHandler] - Connection to Lightwave in tact

I hope that helps …

While I’m writing, can I add the Gen1 hub as a Thing? Is it a h21 device? (I tried on 1.1.1 but didn’t seem to get me anywhere!)

Ben

@BenDWire try this…
removed
i havnt integrated the gen 1 hub yet as didnt have the data. run discovery, add the hub (will be unknown device). then go to the thing and check the properties, it will list all the channels it supports. if you send me this i can add it to the binding

I’m trying to update this - I have removed it all and added the jar file to my addons folder but openhabs not picking it up at all???

After updating to 1.1.3 it took 2 reboots before the account went online, but I’m stumbling at the “Run Discovery” step. As the logs show below, I think OpenHAB is tryng to discover in the background and failing. I then ran “smarthome:discovery start lightwaverf” in the console which threw the error on the last line.

Noob question - Am I doing the “Run DIscovery” correctly? I tried appending .discovery to the command, and also using “LightwaveRF” in case it’s case sensitive, but got nowhere.

If you can give me a few pointers as to what I’m doing wrong I’ll try again.

Thanks again for trying to get this working!

2020-02-22 01:35:43.984 [DEBUG] [rf.internal.handler.LWAccountHandler] - Initiate Polling
2020-02-22 01:35:43.986 [WARN ] [rf.internal.handler.LWAccountHandler] - Channel List For Updating Is Empty, rescheduling
2020-02-22 01:35:52.865 [DEBUG] [rf.internal.handler.LWAccountHandler] - Checking Lightwave connection
2020-02-22 01:35:52.867 [DEBUG] [rf.internal.handler.LWAccountHandler] - Connection to Lightwave in tact
2020-02-22 01:35:53.988 [DEBUG] [rf.internal.handler.LWAccountHandler] - Initiate Polling
2020-02-22 01:35:53.991 [WARN ] [rf.internal.handler.LWAccountHandler] - Channel List For Updating Is Empty, rescheduling
2020-02-22 01:35:58.957 [WARN ] [nternal.DiscoveryServiceRegistryImpl] - No discovery service for binding id 'lightwaverf' found!