ok its been a while for me, just had back surgery so im playing on computer a lot.
i orginally made a post
so i am setting up a web server, dns, vpn, ngnix on a docker all my outside traffic will go through this so i can set up logins and pass for people to log into my dashboard and brew a beer with me remotely.
now the questions. or what i have exploding in my noggin.
i have to set temperatures on my fermenters depending on what is in them.
i am using the drop down ui to set a specific number for payload.
i plan on keeping my dashboard running normally on my pi but am only going to grant access to the nodered instance on my docker server.
what would be the best way of keeping things working together.
can i have a drop down on both instances of node red selecting a temp. or should i have the accessed flow be the deciding selector. and in my originall i just have a digital display that says what was selected.?
I hope i make sense here?
if not slap me into oblivion or the correct direction.
cheers,
Billy Jack
so before going in to the technical details, what do you want the user to do? Do you really need a full node-red instance for that, or would access to some web overview with a set of fancy buttons do enough for them?
So my plan is to allow the users to see temps, set temps, control pumps and water supplies to actually brew a beer remotely from all over the planet.
aka no one has had a person from every continent log into a dashboard and brew a beer remotely before. i plan to be the first.
so. I have my main node red that will actually accept parameter's aka a set temp for a fermenter.
however the login node red instance will just allow someone to turn a pump on or off or open a valve and so on.
it would be actually nice to have 2 drop downs communicate. aka
if online instance get changed to "cold crash" (38 degreesF)
then the internal dropdown will show that is what's selected.
but if that is to difficult, im ok with the dropdown being just on the online instance, and ill set up a display on the main that says what was selected.
i do have the "online" (its actually on a seperate computer in network)
linked right now just did the controls for the 3 fermenters and its displaying temps.
however i disabled the dropdown on the main and just have a digital ui node displaying the set temp in bottom right corner here is pics
alright here is my problem.
I have a switch in main node-red, and a second switch in secondary node-red on a seperate device.
how do i create a loop between the 2. i have figured out how to control the actual gpio pin from either instance of node red. However if i switch on on main node. the secondary switch doesnt change position to show its on. and vise versa for if i change switch on secondary node-red.
is it possiblek to create a safe loop between the 2 without create some kind of yoyo effect where they just keep switching states.
thanks,
I think you would be best looking at using MQTT and looking at retained data in their - both NRs could subscribe/publish to MQTT and this would become your source of truth.
You would run a polling routine to check the various MQTT topics and set your dashboard to reflect their state
ALternatively with your remote NR - why not go for either Flexdash or UIBUilder (both of which seem to address Multiuser with a different data model to the traditional dashboard
hmm.
ok ill read those and see what i can do on that.
I am using mqtt.
im setting up the secondary node-red to have a secure way for people to join in.
and to keep my main instance behind locked doors.
I am probably overthinking how it goes.
and i now have myself lost my spaghetti lines of nodes that i dont know which ones are working and which ones are not at the momment.
Your other option is to host the remotely accessed NR on a Virtual Servers somewhere (Linode is good and cheap for this sort of thing) - put a basic webpage on it so the users only have limited access (whatever you define in the webpage) rather than the NR dashboard and then have the NR instance communicate back to you main server
Remember there is always someone smarter than you out there who will want to access your system - so if you are going to open it up then better off restricting them outside your network and only allow a limited number of external nodes (i.e. one VPS) over a defined comms channel with defined acceptable data structures into your network.
yes thats the actual plan, im just setting up the flows and figuring out how it is going to work on the second instance.
noone will have access without login credentials.
and i can easily revoke those on the fly. using ngnix and reverseprox set up. I always have an escape plan! everything that is actually controlled by node-red is actually setup in my physical control panel to either be "off", manual, or Auto(controlled by Node-red.)
I have already fried a pi doing something stupid in my wiring so i can on the fly turn things off . or manually turn them on and control my system without using node red.
Yes the login credentials is not the issue - you are not a security professional so updates etc will get past you at sometime.
You should engineer on the basis that you will be compromised at some point and then work out what the minimal footporint is that you need to expose your live system with to still get the job done.
So the front end node has a point to point VPN back to your inhouse MQTT broker and a firewall at your inhouse broker that only permits secure MQTT down that link - that broker is in a DMZ on your inhouse network and nothing else can talk to it
Then you have a process on your live NR that only subscribes to a set topic on the dedicated broker and no other traffic is allowed out from that Broker into your Internal Network. The rest of your internal devices use a different broker - not the one that is exposed to the outside world
