@markus This was the secret ingredient. 
I shutdown my RPi.
Now when I pressed ‘Register’ the LWRF hub started to flash (correct response) and when I press the register button on the LWRF hub it dims. (Again correct response).
Now, using the flow you posted and amending to my IP addresses, I can control my LWRF devices.
The problem I’m going to have I suppose is that it is going to be one thing or the other.
I guess I will set up NR flows for my LWRF devices using HE linked devices. When I’m happy they are working as expected, I can then shut down my RPi and substitute the HE devices.
Thanks again for doing this.
The more I’m using CC the more I’m liking it and the more experience I’m gaining.
Thanks again. What a team!!!
4 Likes
Glad to hear it’s working
Do you have the model with a two-row display on it? The implementation I wrote is sending a message to display based on the command sent, just curious if it works. Do you have colour devices as well? Would be interesting to hear if all features work as expected, like mood, dimming, colours etc. If all is well I’ll repost it as a 3rd party integration so that it’s easier for people to find in the future.
Btw, the “simulator” that was included in the flow you can delete if you want, it was there since I had no real LWRF device to develop against but wanted “proper” replies.
1 Like
I’m using the V1 hub and devices. These are ‘stateless’ devices I’m afraid so they do not actually report their current state. The devices and hubs are not interchangeable either. 
The V2 hub and devices do I believe.
LWRF Hub
The only devices I have are dimmers (accepts on/off/dim commands) and outlets (on/off).
Going to be an early start/long day when I move the devices over. Can do most of the work first though by using HE devices in NR to write the flows.
EDIT: I know there are people on HE with Gen 2 hubs that are trying to get them to work with HE. Not sure if anyone has them working though.
2 Likes
The subflow node I created for this could be made to store the current “state”, but not sure that is of any use, for now they just display the latest command sent as their status, but doesn’t store it anywhere.
Do you get responses back from the LWRF in the UDP in node?
So first automate the devices you have on HE and then switch to using this integration instead of using those devices?
Ok, this integration probably would support those, if they use the energy and power parts of the API additional parts would need to be added, but it was fairly easy overall since it seems the documentation was accurate. With accurate documentation it is often a quick thing to do something like this.
I can see the sent command but nothing comes back from the LW hub. I’ve powered up my RPi now to control things will check later.
I know with HE, if I physically turn on the device HE doesn’t know about it so I’d be surprised if I do get a response. I believe the Gen 2 does though. Not sure.
That would be my plan. I will try with a simple flow first for one of my bedrooms and see how it works. If all works well I will do the rest.
1 Like
According to the API docs all versions send a reply, but only later firmware versions send the reply as json. The issue is that the reply only says if the LWRF received the command and sent it, not if the device received the command. Currently the flow I gave you only handle replies if they are in json format, for the other format there wasn’t enough information in the docs to parse it properly so would need some sample data from you for that to confirm what I think is the format. Just connect a debug node directly to the UDP In node and the raw data will end up in debug.
I decided to insert this into a flow for one of my bedroom dimmers and link in to the original flow.
Summary
Turned off the RPi and the flow worked like a charm. 
I didn’t see any response though.
Unfortunately I have turned back on the RPi.
I’ll put a debiu in and the next time I do some testing I’ll see what appears.
1 Like
A small note on the usage of those subflow nodes: you do not HAVE to use change nodes in front of them, you can set the subflow to send a specific dimlevel or on/off (true/false). It is also possible to have ONE subflow per device and just set both the command and the parameter (true/false or dimlevel) in a change node. The different examples and the short helpfile should help to explain it better (displayed when the “book” icon is selected in NR and the node is displayed, just like for other nodes in NR).
1 Like
Thanks for this.
I guess you can tell by how I’ve done things I’m learning.
It was the same with webCoRE and to an extend RM on HE, the more you use it and the more experience you gain, the more you realise how you can streamline things.
2 Likes
Hi @markus
I’ve been doing some more testing and I’m having some issues with the dimmers.
As you can see from the log below, I try to set the dimmer to 30%, 100% and off.
Unfortunately what ever dimmer level I pick, it just seems to turn it on to a set level and it doesn’t change. I t does turn off OK.
Debug Log
01/09/2022, 10:42:19node: RAW Cmdlightwaverf/5/2/dim : msg : Object
{ _msgid: “3fbb1b908db94527”, payload: “028,!R5D2Fdp10|Dim 30%|R:5, D:…”, topic: “lightwaverf/5/2/dim”, payload_input: 1662025339551, property_payload: object … }
01/09/2022, 10:42:32node: RAW Cmdlightwaverf/5/2/dim : msg : Object
{ _msgid: “d8183f34c1eb6c3a”, payload: “029,!R5D2Fdp32|Dim 100%|R:5, D…”, topic: “lightwaverf/5/2/dim”, payload_input: 1662025352215, property_payload: object … }
01/09/2022, 10:42:35node: RAW Cmdlightwaverf/5/2/off : msg : Object
{ _msgid: “4c2e8e499f2a1806”, payload: “030,!R5D2F0|Off|R:5, D:2”, topic: “lightwaverf/5/2/off”, payload_input: 1662025355319, property_payload: object … }
When using my RPi, I see the following when I monitor the commands.
RPi Commands
Receiver socket listening 0.0.0.0:9761
On request received
Attempt 1 - Sending message: 001,!R5D2FdP9|
On request received
Attempt 1 - Sending message: 002,!R5D2FdP32|
Off request received
Attempt 1 - Sending message: 003,!R5D2F0|
I’m not sure if this helps at all.
Thanks again.
It may be the lowercase “p” vs the uppercase, the API docs had it as lowercase, could be worth changing to uppercase.
Open the subflow for editing and find the function node named “msg.payload to API call”, on row 152, change the following:
`${cmd.parameter !== null ? 'p' + cmd.parameter : ''}` +
to this (only change the p to P):
`${cmd.parameter !== null ? 'P' + cmd.parameter : ''}` +
Changed as requested. 
Did the trick.
Thank you so much.
I’ll transfer more across and see what happens.
I lost significant WAF when lights were playing silly beggars Tuesday Night/Wednesday morning.
Time to risk things again.
1 Like
Change is always risky 
Glad it’s working
1 Like
Hi @markus
I’m finding that occasionally my LWRF devices get ‘erratic’.
Some work, some do not.
If I restart NR things are hunky dory again.
I was wondering if there was a way to target the UDP side of things to get things working again instead of a complete NR restart.
Maybe an hourly ‘kick’ to keep things active.
Thanks.
When it happens next, please get the NR logs, there may be something in there showing the reason.
1 Like
Hi @markus
I thought I’d open up NR logs and see what appears when a LW light tuns on.
Nothing appears in the logs for these devices.
I’m using sudo oll-node-red --logs
Is this correct or should I be looking at something else.
That’s correct. do you get any errors in debug when it’s not working? We need to find something that it’s talking to. Try putting a debug node on it for complete message and see if there’s something that will help with some answers there. You’d need to leave NR open to capture these debug messages. Shouldn’t be a hinderance if you’re ok with that.
try running
journalctl -u podman-oll-node-red.service -f -n 1000
This will give you the last 1000 lines of logs. Try scanning in there for anything that looks a bit off.
I’ll point Markus to this when he wakes later.
If you copy and paste those logs into chat, please use the preformatted text icon
</>
It’s above in the toolbar.
1 Like
Thanks April.
Isn’t it the way…
All is working fine at the moment.
I have changed things slightly in the flows that have LW devices in them and this may have solved things.
Too early to say at the moment.
I know that I have some magic home lights (which suck, don’t buy them) 
and if I send commands too quickly to them through Node-RED it crashes them. They’re very unstable. I wonder if that same experience is had with the LWRF? Have you read the data on them to see if something is killing it through node red? Perhaps commands feeding back too quiclky?