@xela what do you want the binding to do if the lightwave server doesnt get the message? Retry?
Yeah, makes sense, can you make it through something in the logs too, would be interesting to see how often it comes up (I dont think i’ve had many occasions where it’s not worked)
i did think it would be easy…
again, lightwave… 
I send a message with a transactionId, great, that means ill get a response to it (the whole point)…
So sent message, detailing its a request, with transactionid 19…
{
"version": 1,
"senderId": "448f7f67-84d6-4545-a188-f7f77ff71cb8",
"direction": "request",
"items": [
{
"itemId": "0",
"payload": {
"featureId": "5c7d64783c570522afb151b5-285-3157331848+1",
"value": 1
}
}
],
"class": "feature",
"operation": "write",
"transactionId": 19
}
Pity the response doesn’t give me a way of tallying up - it tells me its a response to my request but throwing a new random transactionId in there…
{
"version": 1,
"senderId": 1,
"direction": "response",
"items": [
{
"itemId": "0",
"payload": {
"deviceId": 17,
"type": "switch",
"channel": 1,
"writable": true,
"stateless": false,
"virtual": false,
"value": 1,
"status": "ok",
"_feature": {
"featureId": "5c7d64783c570522afb151b5-285-3157331848+1",
"deviceId": "5c7d64783c570522afb151b5-17-3157331848+1",
"productCode": "L42",
"featureType": "switch"
}
},
"success": true
}
],
"class": "feature",
"operation": "write",
"transactionId": 109404095
}
why can they never do things properly… 
i can look up the item, state etc, but what if you send more than one request (easily done with a dimmer for instance), the bindings going to get lost…
@xela 2.5x branch now has a response message listener built in.
It will listen for responses to your commands, if it doesn’t receive an ok it retries up to 5 times (this will be logged).
Failure will also be logged.
Test it out for me as only basic testing done. May need to play about with the timings.
Will load it this evening
And if any of you have sonoff devices, just published a new binding here:
Loaded it earlier so far so good, restarted the hub and tried to send a command and as expected:
22:12:53.609 [INFO ] [f.internal.smart.queues.MessageSender] - Ok message not received for transaction: 8182, command was null : 0 for Device: null, retrying again. Retry count 2
22:12:54.712 [INFO ] [f.internal.smart.queues.MessageSender] - Ok message not received for transaction: 8182, command was null : 0 for Device: null, retrying again. Retry count 3
22:12:55.815 [INFO ] [f.internal.smart.queues.MessageSender] - Ok message not received for transaction: 8182, command was null : 0 for Device: null, retrying again. Retry count 4
22:12:56.918 [INFO ] [f.internal.smart.queues.MessageSender] - Ok message not received for transaction: 8182, command was null : 0 for Device: null, retrying again. Retry count 5
22:12:58.022 [ERROR] [f.internal.smart.queues.MessageSender] - Unable to send transaction 8182, command was null : 0 for Device: null, after 5 retry attempts
Only thing is when it fails openhab has left it at the value it attempted to set, do you have easy access to the previous value so you could revert it maybe?
Yeah I can revert it.
Glad to see its working tho.
Need to sort them nulls out in the log tho
What I didn’t manage to do, was get it to succeed, but I need to try and time the update perfectly so the hub has rebooted somewhere between 0 and 5 retries 
Could you maybe make retries a configurable option so I can increase it to test?
I’ll add a configurable option into the account parameters. Will try and get done later on, but im going to working on the binding thursday if not getting gen1 finished.
No worries, I’m in no rush for any of it and really appreciate all the work you’re doing
All good, improvements always welcome.
This path all started as I wanted to create an app & webservice for my business data without the cost of development which I was looking in excess of 50k.
As that was bespoke I was finding it extremely difficult to even get started… So, with the help and support here I’m learning to code and will save myself a lot of money in the long run hopefully 
@xela Did you see my post the other day…
Forum crashed so all messages deleted for 6th&7th.
If not I’ll try and remember it all 
I did, but I can’t remember it all, I’ll see if I still have the email
Just uploaded a new version guys.
2.5.x: lightwaverf/org.openhab.binding.lightwaverf-2.5.13-SNAPSHOT_v3.0r1.jar at master · delid4ve/lightwaverf · GitHub
- Fixed initial refresh data
- General speed improvements
- Gen1 support added (not complete) and need testers/helpers to finish integration
- Fixed connection status for devices
- Fixed energy reset command
- Fixed voltage rest command (if the device has weird data on power/voltage/energy
- Lots of other minor bug fixes
Your going to need to clear the cache after removing your existing jar as alot has been done to get this ready for a PR into the main repo.
Will upload 3.x version over the next couple of days.
Let me know if you find any bugs
Having some issues with this one, the websocket seems to randomly die.
My heating didnt come on this morning (openhab had changed the values locally), when I attempted to change I get the following
10:04:55.252 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'lw_LR1Heating_targetTemperature' received command 20.5
10:04:55.254 [INFO ] [arthome.event.ItemStatePredictedEvent] - lw_LR1Heating_targetTemperature predicted to become 20.5
10:04:55.259 [INFO ] [ternal.LightwaverfSmartCommandManager] - **Message not added to queue as we are shutting down**
10:04:55.261 [INFO ] [smarthome.event.ItemStateChangedEvent] - lw_LR1Heating_targetTemperature changed from 20 to 20.5
10:05:03.535 [INFO ] [smarthome.event.ItemStateChangedEvent] - lw_Monitor_Power changed from 1458 to 1469
10:05:03.537 [INFO ] [smarthome.event.ItemStateChangedEvent] - lw_Monitor_EnergyUsage changed from 3172.169 to 3172.175
10:05:11.722 [WARN ] [connections.LightwaverfSmartWebsocket] - LightwaveRF - Closing a WebSocket due to null
10:05:11.726 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lightwaverf:lightwaverfaccount:alex' changed from ONLINE to OFFLINE
10:05:11.727 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lightwaverf:d22:alex:LivingroomDimmer' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
10:05:11.728 [WARN ] [connections.LightwaverfSmartWebsocket] - LightwaveRF - WebSocket connection closed
10:05:11.728 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lightwaverf:d21:alex:OfficeDimmer' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
10:05:11.730 [WARN ] [connections.LightwaverfSmartWebsocket] - LightwaveRF - Closing a WebSocket due to NullPointerException
10:05:11.730 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lightwaverf:d21:alex:RyanDimmer' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
10:05:11.731 [WARN ] [connections.LightwaverfSmartWebsocket] - LightwaveRF - WebSocket connection closed
10:05:11.732 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lightwaverf:h21:alex:LightwaveHub' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
10:05:11.733 [WARN ] [connections.LightwaverfSmartWebsocket] - LightwaveRF - Closing a WebSocket due to Disconnected
10:05:11.733 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lightwaverf:d21:alex:BedroomDimmer' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
10:05:11.734 [WARN ] [connections.LightwaverfSmartWebsocket] - LightwaveRF - WebSocket connection closed
What’s odd, is it’s still receiving updates from the Monitor in the middle of it. It doesn’t recover though until I restart the binding
I’ll have a little look later and let you know. Jetty web socket implementation is a pain in the backside, slightest discrepancy in the forward chain and it disconnects it. Probably something very minuscule somewhere.
Can you get me the debug logs as this will show me where it failed.
Is it actively creating a debug log, or do I need to turn them on, I’m running in INFO at the moment