Hi,
I got above working, it’s gr8! But... it only receives msg.payload, and not msg.topic as well of the msg object.
Any change this can be done for UDP send and receive?
No, a UDP packet doesn't have any structure - it is whatever bytes you provide in msg.payload.
If you want to include more information, then you'll need to encode it into the payload, for example, a JSON string with the payload and topic properties in it.
Okay, got it, thank you.
Hi @IoTPlay,
I'm sure you already know this but if you use mqtt between the two (assuming two node-red instances or something you have control of), you will get the topic without any extra work encoding decoding a message. Just a thought.
Yes, I am using MQTT in production between 2 Pi's - but looking for a docker to docker container on the same host comms - busy splitting a large home control system into 'domains' - and love the fact that the 2 dockers can talk to one another, without anybody beign able to snoop in -as they are both on the same docker network. ut, as you say, it comes with some overhead....
I see. You seem to know your stuff - nice.
Have you perhaps considered using an MQTT broker on one of the dockers that is limited to only the private interface (or protected/locked down)?
Again, just a thought. I'm pretty sure there is a broker node for node-red to simplify installing a broker on the docker image.
While I love mqtt as much as the next, it’s not hard to combine topic and payload into a single payload to send over udp. Certainly simpler than setting up docker networking 
2 Likes
100% agree. And if you know what you're doing and that's all you want, knock your self out I say,
That said, on the off chance someone reads this thinking it's (raw UDP) their only option, I do try to impress that is not. I've been surprised by many people insisting on sticking to what they know and shying away from MQTT thinking it was something new fangled / complicated thing but when forced down that path they're all "man this is so easy"
I'm certain the op is well aware of possibilities and hope I haven't come across as teaching him to suck eggs.
1 Like
no problem. and of course there are the docs to be read.
https://nodered.org/docs/getting-started/docker#linking-containers
...using the --link feature of docker is a legacy method, so I personally would not recommend it, see: https://docs.docker.com/network/links/
Using the standard docker networking options is also possible, like a user defines bridge.
If speed is not the highest priority, instead of using UDP, I'd rather recommend using websockets.
Here the complete msg.object can be transfered between sender and receiver node.
Wow thank you for that, gonna try it!
setting up docker networking is peace of cake, when you know basics of IP-networking, especially when using docker management tools like portainer (which runs in a docker as well).
Besides, when running node-red in a docker, networking is already used (and configured). All you need to do is use DNS to address the individual instances, which is much simpler that installing multiple node-red instances in one host and fiddling with ports.
my 2 cents.
Got the docker part working and udp one to other container. Did not know about sockets, that it will bring accross full msg object, itwill make it easier. But udp is working very well. Specially since those ports only work inside the container to container service I setup. Thanks to all for thinking with me on this. Opens a new design paradigm to modularise the application,
I built a ‘broker’ that makes non Homie devices homie compliant, same broker configures your home with a yaml file for that. No config happens in the flows for your house, all in the yaml files. The broker and ‘protocol translator’ also has a HomeBridge yaml config file, that works with 1st config file, and routes msgs between devices, storage of the ‘digital twin’ of the house, translates forward and backward between homie, espeasy, HomeBridge, shelly, and RFBridge, and Paradox alarm system. All devices back and forth via mqtt. The ‘digital twin’ - or ‘homedig2’ updates a global context json file, stored in homie structure. Have experimented with couchDB for proper storage - future design. This is gr8 for reporting, as all reports for everything in the home now reads off the homie based dig2.
2nd docker container, inside same docker network contains all the test packs which talks via udp to 1st container, as if it is sending an mqtt msg (goes to same entry point as mqtt on the broker).
This talks to homeBridge docker container via mqtt, outside the docker network, on another pi, that hosts a few other things.
3rd container inside same docker network contains all custom stuff for the home, and talks to broker - I might also move this over to udp. It contains a sprinkler system, and garage door opener mostly running on esp8266, talking back to mostly homeBridge. Which then interacts with Apple Home apps (opensource HomeKit style). But I catch the homBridge mqtt messages on the broker as well, and then update the home digital twin.
The early design docs is on github on IoTPlay/homedig2. But the solutions has been running in my home in previous design i carnation for the last year.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
