websockets / NodeRED

[J V]

Hello,

I have a question regarding the use of websockets to communicate with the Loxone Miniserver.

Are there any best-practices or things to avoid you plan a config where you will control/monitor with websockets?

In my case, I want to control some devices (e.g. an amplifier) via NodeRED and as I understand it the best two-communication is using websockets (via node-red-contrib-loxone ). However, it does seem to me that you are a bit constructing things blindly: you just make control elements which you will access via the websockets - there is no single device in the Tree, no entry in virtual inputs or outputs, no templates... So does that mean you have to just organize with pages, category and room? So you make e.g. a knx button, named it logically and just leave it disconnected as all changes will go via the websocket? (just trying to wrap my head around it)

Just to give some context: I currently have a PC which runs Eventghost, and communciate with it through virtual inputs and virtual outputs, with defined templates for various devices. I'm now considering to move to something else as my Eventghost configuration was hard to maintain and I had a lot of duplication between my Loxone config and my Eventghost config. Since some database-crash, the Eventghost website went offline, together with the vast knowledge in the forum. The project was moved to github, but there is much now a much smaller active community, so I figured it is time for a change.
NodeRED seems to be the way to go, I've found flows that can control my TV, and I should be able to manage almost everything. But I need to redo big parts of my config, hence the question on some pointers to get started.

Thanks,

Jörg

[GertSt]

Hi Jörg,

I'm using Node-Red to communicate between some devices in Home Assistant and Loxone. Home Assistant has a Node-Red integration, and in there I'm using the plugin node-red-contrib-loxone. The one that you also mentioned.
That does work, but not very robust: The plugin disconnects from time to time (once in a few months) and I'm not sure why. Sometimes it reconnects automatically, but I also have to manually reconnect sometimes, by deploying Node Red again (=one click action, but I hate it that it's not robust).



From Loxone to Node Red, I use the node "stream in": there you can filter on Loxone Category. I made a Category "Home Assistant" for all my controls that should go to Home Assistant (Node Red). In Loxone, I have Virtual Outputs that send various commands to Node Red. This way I can turn on lights, set their RGB value, turn on TRVs, control the Zehnder ventilation, and so on.

From Node Red to Loxone, I use the node "webservice". This send commands to Loxone using Virtual Inputs. This sets mostly feedback from my devices to Loxone: In Home Assistant I have several Zigbee devices that send their status back to Loxone, like TRVs, window contacts, Hue Lights, PIR sensors, a CO2 meter, ventilation status, ...

This system makes your Loxone very open to any possible device on earth, and at a fraction of the cost of native Loxone devices. But it takes some time to set it up and to maintain it. It also is not that stable. I do not use it for important home automation devices, but even then, I would not recommend it if you want to go for a rock solid solution.



Gert

[J V]

Thanks!
I think maybe I misunderstood something. My current configuration with EventGhost was based on virtual inputs and outputs, but I thought it could be simpler with websockets.

You use virtual outputs to send states to NodeRED; I thought the websockets allow you hook into e.g. a control and that that would be sufficient to get its state changes. The documentation mentions that "In the following document a “Control” is a Function/Block-Function like “Virtual Input”, “Virtual State”, “Intelligent Room Controller”, “Sauna” etc":

https://www.loxone.com/wp-content/uploads/datasheets/CommunicatingWithMiniserver.pdf

I thought that is what the control-in node is for, so you can hook into a radio button, pushbutton or whatever... Could be useful though to catch all events from a category/room... but don't the websockets allow you to be free from the virtual output?

Similarly, I was thinking of triggering the Loxone controls directly rather than using virtual inputs, which I thought would be possible (I have triggered switches that way, using simple webservices).

Am I misinterpreting how these websockets work?

(edit: I realized I linked to an older document)

[J V]

Just checked... Using the "Control In" node, I can connect to a block in my loxone config (I tried with a radiobutton and a EIB button). The nodes reflect changes done in e.g. the Loxone app. So there is no need for a virtual output to send something from Loxone to NodeRed. However, it may not be a bad practise to keep things organised, otherwise really gets difficult to keep track of what is used outside of the config.
I haven't yet figured out how the "Control Out" node works as I don't really know in what to pass it and in what format. But the webservice seems like a way to send something directly to a loxone-block

That said, my plan was to use NodeRED as a passthrough from Loxone to other devices (e.g. serial port), so I don't need much decoding in NodeRED: it should just receive a string and pass it on (to/from Loxone).

[GertSt]

You are absolutely right: it is not required to use virtual inputs or outputs, but I did that anyway because I have quite a lot of communication between Loxone and Node Red, and it would be a nightmare to debug if I would change a lot of components directly.

I use the in and outs of the virtual inputs/outputs as I would do with any other sensors/command.

The downside is of course that it takes quite some extra work to set all up.
But even a small typo does result in a non-working connection, so you really want a good way to debug (using Live View in Loxone and Debug nodes in Node Red), so that's why I went for virtual in/outputs.

[GertSt]

I did not go for the dedicated Control in / Control out nodes, because I did not want to create control nodes for all my Loxone components. I went for a more generic listener/controller by using the "stream in" and "webservice" nodes. Using some JavaScript in the function node, I was able to listen to and control several sensors and components with 2 generic functions and some parameters.

Eg: to send all changes of all Home assistant sensors to Loxone, I used this script (snippet of the main part):

if (msg.payload.event_type === "state_changed") {
  //name = msg.payload.entity_id;
  const name = msg.payload.event.new_state.attributes.friendly_na me || msg.payload.entity_id;
  //Send all attributes as separate msg
  Object.keys(msg.payload.event.new_state.attributes ).forEach(attr => {
    //only keep interesting attributes
    if (["percentage"].includes(attr)) {
      sendMsg(name + " " + attr, msg.payload.event.new_state.attributes[attr])
    }
  })
  //send state
  sendMsg(name, msg.payload.event.new_state.state);
}​

This generates a payload that is then converted to a websocket event for Loxone.
Here is the debug trace of some change events.



In Loxone, I only have to set up virtual inputs with a specific name for all the events I want to track. Only the name of the Virtual Input matters to receive a certain value.

Eg:



For the other way around, a similar conversion function is used.

[J V]

Yes... it makes sense! Actually that was the reason for my question... I could see it getting messy. At least I got the websocket part , but it makes sense to limit the communication to easy identifiable controls/nodes.

My main goal is to control an amplifier that is connected via RS232 to a PC (where NodeRED is running). It takes short-string commands and sends back a short string with the result. Earlier I used EventGhost, but as it did not support websockets I had to create a virtual output for every command to the amplifier, and in Eventghost catch every input (they were http inputs) and then send the command. It was a mess to maintain. I initially was looking for a simple tool that could forward TCP to rs232, but had problems finding such tool and realized I cannot send back to Loxone using TCP (Loxberry plugin tcp-udp could be useful here though). NodeRED became an option as it seems to be the easiest way to control my TV (and control it that way from the Loxone app), so I thought it could be used for the rs232 port as well.

I'm now weighing of two options for sending commands to the amplifier.
1. create the exact command-string in Loxone, when a command is triggered send the string via TCP to NodeRED and just forward it to the serial port.
2. use multiple outputs in Loxone, when a command is triggered, catch it in NodeRED and send the appropriate command to the serial port

For the TV I would use an existing flow, so here I will have to go with option 2... but it has much less commands and no return data.

I also need to send back values to Loxone, so for that I have again the same two options:
1. pass the string sent by the amplifier to Loxone, decode it there
2. decode in NodeRED, send the data to correct inputs in Loxone.

Option 1 would make for a very simple NodeRED-flow, with all commands packed in the Loxone-config, so basically just one place to work in.
Option 2 would be a bit more work, with commands packed in NodeRED, but would somehow disconnect the true amplifier commands from the Loxone actions.

Option 2 would make it easier to make a NodeRED user interface, but I don't intend to do that - I want the Loxone app to be my central control. Option 2 would allow to work somewhat transparent from the amplifier's commands, but I don't see a need for that - it won't be replace anytime soon... The commands for the amplifier do not exist in any other flow, so I would have to make them anyway. Option 1 would mean a bit of string-operations in the Loxone.

EDIT: Just starting it makes me realize there actually is a third option: make multiple output commands rather than building the string. There will be many output commands in Loxone, but they all go to the same TCP port (and thus the same NodeRED node). And it will look a lot like your approach: 1 virtual output (the NodeRED computer), with multiple virtual output commands. For the data sent from NodeRED to Loxone I need a lot of decoding: the values are codes which I need to translate, so I might as well just receive a string (1 virtual texty input) and parse it. the parsing at the same time will trigger the decoding. Otherwise I have to parse it in NodeRED (to identify which value it is), and then send it all to seperate nodes to then translate it. It seems easier to combine that step as one in the Loxone config: command recognition would immediately identify the command and give me the value..

[J V]

Our replies crossed... I could do something similar for sending values back to Loxone, but would still need to have processing there do present the data (the amplifier sends back codes, to visualize I need to translate those to string - e.g. the name of the input or the type of input signal.

[GertSt]

These all look like valuable and well thought out solutions

There are indeed a lot of possibilities, and it depends on personal preference what option to use.
I like the JavaScript coding of the function block in NodeRed, because I know the language well. For me, writing some logic in JS is more straightforward than setting up wiring diagrams in Loxone.

I suggest to test various scenarios with a small set of commands, just to make your feet wet and see what works the best for you ;-)

[J V]

Thanks for helping to straighten my thoughts on this. I know a proper planning can help a lot.

It seems like Loxone -> NodeRED is quite simple: virtual output (tcp), multiple virtual output commands, NodeRED listens on the tcp port and passes on what comes in.

My main issue is that I want to interpret the return values of the amplifier. It returns for example "SRC:1" to indicate that the source is TV. But of course in the Loxone app I want to display the string "TV" . Decoding the value to a string in NodeRED means I have to pass it to Loxone using a virtual text input. But then I don't have the number of the input (which could be useful for e.g. a radiobutton), so I should also pass that one to a virtual input. Just passing the latter and decoding it in Loxone seems easier: half of the virtual inputs needed, and a command recognition connected to a status block suffices to give it both the string and a number.

I did the previous config to work together with Eventghost, but moving to NodeRED means I have to temporarily would need maintain three systems, however as the serial port cannot be shared I need to move all that functionality at once... So it is a bit messy for testing. :-)

But thanks again for your inputs and advice, it was really helpful.