How much work/extra load would it be for the binding to retrieve the value of a feature after updating it, to ensure the link plus received the command?
1 line of code 
Just working on sonoff binding atm, I’ll add in later today or tomorrow 
Great, I was in the dog house when the bedroom was 14degrees last night 
How did it happen…
I’m assuming you did send a warmer temp than that
Is there anything in the logs? Ie websocket was disconnected etc
Absolutely nothing, it changed locally on Openhab, at the same time as the ensuite and landing trv but checking at 11pm, it hadn’t changed on the unit itself:
2021-01-30 21:00:00.077 [ome.event.ItemCommandEvent] - Item 'swBedroomHeating' received command ON
2021-01-30 21:00:00.083 [ome.event.ItemCommandEvent] - Item 'TimelineHelper' received command {"TI_KidsRoomHeating":{"inactiveLastValue": "OFF"},"TI_LivingRoomHeating":{"inactiveLastValue": "OFF"},"TI_KitchenHeating":{"inactiveLastValue": "OFF"},"TI_OfficeHeating":{"inactiveLastValue": "OFF"},"TI_KeiraBlanket":{"inactiveLastValue": "OFF"},"TI_BedroomHeating":{"inactiveLastValue": "ON"},"TI_ElectricBlanket":{"inactiveLastValue": "OFF"}}
2021-01-30 21:00:00.092 [vent.ItemStateChangedEvent] - swBedroomHeating changed from OFF to ON
2021-01-30 21:00:00.098 [vent.ItemStateChangedEvent] - TimelineHelper changed from {"TI_KidsRoomHeating":{"inactiveLastValue": "OFF"},"TI_LivingRoomHeating":{"inactiveLastValue": "OFF"},"TI_KitchenHeating":{"inactiveLastValue": "OFF"},"TI_OfficeHeating":{"inactiveLastValue": "OFF"},"TI_KeiraBlanket":{"inactiveLastValue": "OFF"},"TI_BedroomHeating":{"inactiveLastValue": "OFF"},"TI_ElectricBlanket":{"inactiveLastValue": "OFF"}} to {"TI_KidsRoomHeating":{"inactiveLastValue": "OFF"},"TI_LivingRoomHeating":{"inactiveLastValue": "OFF"},"TI_KitchenHeating":{"inactiveLastValue": "OFF"},"TI_OfficeHeating":{"inactiveLastValue": "OFF"},"TI_KeiraBlanket":{"inactiveLastValue": "OFF"},"TI_BedroomHeating":{"inactiveLastValue": "ON"},"TI_ElectricBlanket":{"inactiveLastValue": "OFF"}}
2021-01-30 21:00:00.101 [ome.event.ItemCommandEvent] - Item 'Notification' received command heating.rules: Bedroom ON
2021-01-30 21:00:00.103 [ome.event.ItemCommandEvent] - Item 'lw_BedroomHeating_targetTemperature' received command 19
2021-01-30 21:00:00.120 [ome.event.ItemCommandEvent] - Item 'lw_EnSuiteHeating_targetTemperature' received command 17
2021-01-30 21:00:00.140 [ome.event.ItemCommandEvent] - Item 'lw_LandingHeating_targetTemperature' received command 17
2021-01-30 21:00:00.163 [nt.ItemStatePredictedEvent] - lw_BedroomHeating_targetTemperature predicted to become 19
2021-01-30 21:00:00.179 [nt.ItemStatePredictedEvent] - lw_EnSuiteHeating_targetTemperature predicted to become 17
2021-01-30 21:00:00.193 [nt.ItemStatePredictedEvent] - lw_LandingHeating_targetTemperature predicted to become 17
2021-01-30 21:00:00.205 [vent.ItemStateChangedEvent] - Notification changed from heating.rules: Heating OFF to heating.rules: Bedroom ON
2021-01-30 21:00:00.207 [vent.ItemStateChangedEvent] - lw_BedroomHeating_targetTemperature changed from 14.0 to 19
2021-01-30 21:00:00.208 [vent.ItemStateChangedEvent] - lw_EnSuiteHeating_targetTemperature changed from 14.0 to 17
2021-01-30 21:00:00.214 [vent.ItemStateChangedEvent] - lw_LandingHeating_targetTemperature changed from 14.0 to 17
2021-01-30 21:00:06.800 [vent.ItemStateChangedEvent] - lw_LandingHeating_CurrentTemperature changed from 18.5 to 18.4
2021-01-30 21:00:06.894 [vent.ItemStateChangedEvent] - lw_LandingHeating_batteryLevel changed from 85 to 81
2021-01-30 21:00:20.119 [vent.ItemStateChangedEvent] - lw_EnSuiteHeating_batteryLevel changed from 81 to 78
2021-01-30 21:00:20.120 [vent.ItemStateChangedEvent] - lw_EnSuiteHeating_CurrentTemperature changed from 15.5 to 15.2
2021-01-30 21:00:20.190 [vent.ItemStateChangedEvent] - lw_EnSuiteHeating_valveLevel changed from 0 to 30
2021-01-30 21:00:20.191 [GroupItemStateChangedEvent] - Lightwave_Heating_Valve changed from OFF to UNDEF through lw_EnSuiteHeating_valveLevel
2021-01-30 21:00:20.191 [vent.ItemStateChangedEvent] - lw_EnSuiteHeating_callForHeat changed from OFF to ON
2021-01-30 21:00:20.192 [GroupItemStateChangedEvent] - Lightwave_TRV_CallforHeat changed from OFF to UNDEF through lw_EnSuiteHeating_callForHeat
2021-01-30 21:00:20.297 [vent.ItemStateChangedEvent] - lw_Monitor_EnergyUsage changed from 2056.923 to 2056.928
2021-01-30 21:00:20.336 [ome.event.ItemCommandEvent] - Item 'lw_Heating_targetTemperature' received command 30
2021-01-30 21:00:20.339 [nt.ItemStatePredictedEvent] - lw_Heating_targetTemperature predicted to become 30
@delid4ve Which binding are you actively working on going forward, the V2 or the V3? Just asking to see if I need to bite the bullet and upgrade my OH to V3…
I’m doing both
Only takes a few minutes to sync the changes.
I’m running 2.5.11 still and have no plans to upgrade yet as there isnt a 3.x version for my qnap nas yet.
Plus I really dont like the new ui at the moment. prob just need to get used to it.
@xela i’ll implment them changes today, sorry, got bogged down with sonoff.
@Fixer ive changed the first post in this thread, there are 2 repositories, one for 2.5.x and one for 3.x. Ill keep them in sync with any changes i make.
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.