Welcome to the W0QL remote station journal. The station was born in 2016 and is located 35 miles east of Denver. It’s controlled over the Internet and powered exclusively by solar panels.
Inside, on the counter is the Flexradio transceiver, the heart of the whole station.
Now let’s get going, with the most recent post beginning below.
In Part 1, Modbus data was figured out and it’s floating point output was converted to decimal. Additionally, knowledge of how to activate relays using Node Red was achieved.
In Part 2, the first sub flow will listen for a High Voltage Disconnect (HVD) and activate a relay accordingly. The sub flow will do a modbus read of a solar controller, and listen for the HVD bit. Morningstar solar controllers activate HVD when a Lithium battery is fully charged, to prevent overcharging . When the HVD bit is positive, Node Red will tell the 1216H to close a relay corresponding to that controller. The closure in turn opens a higher current relay and disconnects the panels and RFI stops. RFI is generated when a controller is allowing the solar panel to run with no load. Let’s begin.
Here is the first section of the flow, which retrieves the byte that contains the HVD bit, bit 4. The address and the bit position are in the Morningstar documentation at this link: https://www.morningstarcorp.com/wp-content/uploads/technical-doc-prostar-modbus-specification-en.pdf
Refer to the figure above as the remaining nodes are explained.
Focus on the node in the upper left corner that says, “Strass Gray HVD”. This is the Modbus-Read node which retrieves the byte with the HVD bit. It is configured in the pane below. A polling rate of 1 minute is adequate to determine when a battery is fully charged.
In the next node down, labelled “bit 4”, in the flow above, the correct bit is extracted from the byte, which is bit 4, per the Morningstar document. The tool chatGPT was asked to write a Node Red function using javascript to select bit 4 of the input, and output the selected bit. Below, the result has been copied and pasted into a function node. It looks like chatGPT started on the first bit and rotated to the right three times to get to bit 4.
Next node down is a switch node, labelled simply “switch”. A switch node can be thought of as an if-then-else logic block. If the input is one state the switch will output a result to one of it’s output ports. If the input state is different the switch will output to a different port. Here the switch is being used to output a 1 on the top port when the input is a 1, and a 0 to the bottom port when the input is 0.
Continuing around the flow, the next node down is an Inject node labelled “0”. When clicked on, this node will inject a 0 into the switch node. This will cause the relay to be turned off in case of emergency.
The next node down is a link. A link node takes the data from it’s input and links it to another link node somewhere else in the flow and transfers the data. In this flow the link is taking the data from the top output of the switch node and linking that data to the input of a node that will do a reset in that other flow. The logic behind doing this reset is as follows. When the top output of the switch is active that means a High Voltage Disconnect has occured because a battery is fully charged. Since the battery is fully charged it is at a State Of Charge (SOC) of 100%. The link to another flow resets a gauge for SOC to 100%. This allows the SOC to be calibrated each cycle. Next the nodes on the right-hand side will be explained beginning at the top.
The top node on the right is the Modbus Response. This node is necessary to complete the conversation with the mod bus, which was started by the Modbus Read node.
Next down the line is a complicated looking node with a lable of “curl http:\\192.168…..”. This is an exec node which has the power of executing any command that could be executed at the shell prompt (command line interface or CLI) of the machine running the node red application. In this case the command is a “curl”. Hubspot defines curl this way:
A command line tool that enables data exchange between a device and a server through a terminal. Using this command line interface (CLI), a user specifies a server URL (the location where they want to send a request) and the data they want to send to that server URL.
In other words, we can execute a command to go to a web page, in this case the Microbits 1216H module. Here is how the exec node is configured:
Notice the i.p. address above is a private local address. This address could just as easily be an address anywhere on the Internet and Node Red could do it’s job from a remote location any where in the world that has Internet access.
Next down is a function labelled “change msg.payload”. This node takes the “1” in the payload given it by the switch node and changes the payload output to “DISC” which stands for “disconnect”.
A similar function node is next down except this function node changes the payload to “NORM” which stands for normal. Both of these last two nodes feed into a text node which had the purpose of printing text to a dashboard. The configuration is slightly unusual in that two words are printed to the dashboard by the text node. The first word goes into the label field, in this case HVD. The second word comes in as the payload from the previous node, in this case either DISC or NORM.
This concludes the HVD subflow. Subflows remaining to be documented when time permits are:
The chain of subflows is duplicated three more times, one for each battery lineup.
https://www.webswitch.se/wp/?page_id=342
e.g.
http://ws.microbit.se:82/relaycontrol/on/1
|000|OK|1|1|
http://ws.microbit.se:82/relaycontrol/off/1
|000|OK|0|1|
Version 1.20 and newer has improved and extended support for controlling the relays(including Nexa remote switches), getting the status of the digital inputs as well as reading temperatures from 1 wire sensors via HTTP GET URLs. Version 1.23 adds the possibility to read the state of the relays.
Turn on only one relay or Nexa remote switch using an index number:
http://[webswitch address]/relaycontrol/on/[a number]
[a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25, version 4.0-> 201-225=local 1-wire digital outputs, version 4.31 HOME Denkovi 8 > 256-456
Turn on only one relay or Nexa remote switch using its name:
http://[webswitch address]/relaycontrol/on/[relay/Nexa name]
[relay/Nexa name] has to be URL encoded.
Turn off all relays and Nexa remote switches:
http://%5Bwebswitch address]/relaycontrol/off/all
Turn off only one relay or Nexa remote switch using an index number:
http://[webswitch address]/relaycontrol/off/[a number]
[a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25, version 4.0-> 201-225=local 1-wire digital outputs, version 4.31 HOME Denkovi 8 > 256-456
Turn off only one relay or Nexa remote switch using its name:
http://[webswitch address]/relaycontrol/off/[relay/Nexa name]
[relay/Nexa name] has to be URL encoded.
Home:
Pulse a relay high(on) for a selectable duration in seconds:
http://[webswitch address]/relaycontrol/pulse/high/[relay/Nexa name/number]/[duration in secs]
See above for [relay/Nexa name/number]
Home:
Pulse a relay low(off) for a selectable duration in seconds:
http://[webswitch address]/relaycontrol/pulse/low/[relay/Nexa name]/[duration in secs]
See above for [relay/Nexa name/number]
Get current relay/Nexa state using its name:
http://%5Bwebswitch address]/relaystate/get/[relay/Nexa name]
[relay/Nexa name] has to be URL encoded.
Get current relay/Nexa state using an index number:
http://%5Bwebswitch address]/relaystate/get/[a number]
[a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25
Turn on two or more relays or Nexa remote switch using index numbers:
http://%5Bwebswitch address]/relaycontrol/on/[a number]$[a number] etc
[a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25
Example: Turn on relays 2, 3, 5 and Nexa 1:
http://%5Bwebswitch address]/relaycontrol/on/2$3$5$101
Turn off two or more relays or Nexa remote switch using index numbers:
http://%5Bwebswitch address]/relaycontrol/off/[a number]$[a number] etc
[a number]: 1-5=built-in relays, 6-10=extension relays, 101-125=Nexa remote switches number 1-25
Example: Turn off relays 1 and 4:
http://%5Bwebswitch address]/relaycontrol/off/1$4
Getting relay state by index, multiple relays:
http://[webswitch address]/relaystate/get2/[a number]$[a number] (and so on)
The answer will be something looking like:
1,0
2,0
5,1
for an url looking like this: http://[webswitch address]/relaystate/get2/1$2$5
Ham/Home
http://%5Bwebswitch address]/relaycontrol/pulse/[relay]
relay=1-10
For reading digital inputs:
Input 1:
http://[webswitch address]/input/get/1
Input 2:
http://[webswitch address]/input/get/2
Local 1-wire inputs:
http://[webswitch address]/input/get2/[a number]
[a number]: 1-25=1-wire input number 1-25
Note that since it’s a dual input devices the answer will look like this:
|[3-digit status code]|[Message in text]|[value]
With [value] being formatted as A,B for input A and B, for ex. 1,0 means input A=1 and input B=0
Reading by index:
http://[webswitch address]/temperature/get/[1-25]
Added in version 3.7:
Reading “temperatur.nu” temperature:
http://[webswitch address]/temperature/get/26
Reading by sensor name:
http://[webswitch address]/temperature/get/[sensor name]
[sensor name] has to be URL encoded.
Reading by index:
http://[webswitch address]/temperature/get2/[1-25]
Added in version 3.2:
Reading by index, multiple sensors.
http://[webswitch address]/temperature/get2/[1-25$1-25$1-25] (and so on)
The answer will be something looking like:
2,24.4
3,21.4
4,23.8
for an url looking like this: http://[webswitch address]/temperature/get2/2$3$4
Reading by sensor name:
http://%5Bwebswitch address]/temperature/get2/[sensor name]
[sensor name] has to be URL encoded.
Added in version 4.17:
Reading max temperature by index:
http://[webswitch address]/temperature/get/[1-25]/max
Reading min temperature by index:
http://[webswitch address]/temperature/get/[1-25]/min
Reading max temperature by sensor name:
http://[webswitch address]/temperature/get/[sensor name]/max
[sensor name] has to be URL encoded.
Reading min temperature by sensor name:
http://[webswitch address]/temperature/get/[sensor name]/min
[sensor name] has to be URL encoded.
Added in version 4.21:
Resetting max/min temperatures:
http://[webswitch address]/temperature/reset/now
Getting date/time for last reset of max/min temperatures:
http://[webswitch address]/temperature/reset/last
Example of reply: |000|OK|2015-09-17 14:49|
Reading by index:
http://%5Bwebswitch address]/rh/get/[1-25]
Reading by sensor name:
http://%5Bwebswitch address]/rh/get/[sensor name]
[sensor name] has to be URL encoded.
Reading by index:
http://%5Bwebswitch address]/rh/get2/[1-25]
Reading by sensor name:
http://%5Bwebswitch address]/rh/get2/[sensor name]
[sensor name] has to be URL encoded.
Added in version 4.81
Reading by index:
http://%5Bwebswitch address]/rh/get/[30-32]
Get the state of the car heaters:
http://%5Burl%5D/carheaterstate/get
See below for the reply format.
Set the state of the car heaters:
http://%5Burl%5D/carheatercontrol/set/override/%5Bheater name]/[command]
[heater name]: name of the heater
[command]: disabled, off, on
http://%5Burl%5D/carheatercontrol/set/override/%5Bheater name]/[command]/[hour]/[minute]
[heater name]: name of the heater
[command]: today or tomorrow
[hour]: hour of departure time in format 0-23
[minute]: minute of departure time in format 0-59
Get the state of the Auto Control Programs:
http://%5Burl%5D/acpstate/get
See below for the reply format.
Set the state of an Auto Control Program Override:
http://%5Burl%5D/acpcontrol/set/override/%5BACP name]/[command]
[ACP name]: name of the Auto Control Program
[command]: disabled, off, on
http://%5Burl%5D/acpcontrol/set/override/%5BACP name]/[command]/[hour]/[minute]
[ACP name]: name of the Auto Control Program
[command]: off, on
[hour]: hour to turn on or off
[minute]: minute to turn on or off
Set the state of an Auto Control Program itself:
http://%5Burl%5D/acpcontrol/set/program/%5BACP name]/[command]
[ACP name]: name of the Auto Control Program
[command]: disabled, enabled
Get the state of the Auto Control Programs, including disabled programs
http://%5Burl%5D/acpstate/get2
See below for the reply format.
Getting/setting rotator state:
Get current position in degrees:
http://%5Burl%5D/rotatorcontrol/get
Reply format:
”|000|OK|[degree]” ([degree]=0-359 or >= 360 if no valid readings are available)
Set current position in degrees:
http://%5Burl%5D/rotatorcontrol/set/%5Bdegree%5D
Abort current operation:
http://[url]/rotatorcontrol/set/stop
Set current position using presets:
http://%5Burl%5D/rotatorcontrol/set/preset/%5B1-8%5D
Set power relay on/off:
http://%5Burl%5D/rotatorcontrol/set/power/on
http://%5Burl%5D/rotatorcontrol/set/power/off
Set aux relay on/off:
http://%5Burl%5D/rotatorcontrol/set/aux/on
http://%5Burl%5D/rotatorcontrol/set/aux/off
Get rotator setup:
http://%5Burl%5D/rotatorcontrol/get/setup
See below for the reply format.
Get current position, etc:
http://%5Burl%5D/rotatorcontrol/get2
Reply format:
”|000|OK|[degree],[preset],[power relay],[Aux relay],[Page timeout],[Status message]”
[degree]=0-359 or >= 360 if no valid readings are available
[preset]=Active preset 1-8 or 255 if no active.
[power relay] = Power relay status: 0=Off, 1=On, 2=Not supported.
[Aux relay] = Aux relay status: 0=Off, 1=On, 2=Not supported.
[Page timeout] = Page time out: >0 = page active, 0 = page inactive
[Status message] = Latest status in text format.
Every field, except [Status message], contains only digits.
General format of replies:
General replies are done with Mime type “text/plain” via HTTP in the following format using | as field separator:
|[3-digit status code]|[Message in text]|[status/value]
”|000|OK|[status/value]”
“|100|Unknown command|[status/value]”
“|101|Unknown relay: [id]|[status/value]”
“|102|Unknown input: [id]|[status/value]”
”|103|Not a temperature sensor: [id]|[status/value]”
”|104|Invalid temperature sensor index: [index]|[status/value]”
”|105|Invalid temperature sensor name: [name]|[status/value]”
”|106|Unknown pulse command:[command]|[status/value]”
”|107|Invalid pulse length: [length]|[status/value]”
”|108|Pulsing already active: [relay]|[status/value]”
”|109|Unknown status: [relay]|[X]”
”|110|Unknown car heater: [name]||”
”|111|Invalid time: xx||”
”|112|Not a humidity sensor: [id]|[status/value]”
”|113|Invalid humidity sensor name: [name]|[status/value]”
”|114|Invalid Auto Control Program Override time|[status/value]”
”|115|Unknown Auto Control Program: [Program name]|X| ”
“|116|Invalid rotator preset index|X|”
“|117|Rotator power already on/off||”
“|118|Unknown rotator power command|X|”
“|119|Rotator aux relay already on||”
“|120|Rotator aux relay already off||
“|121|Unknown rotator aux relay command|X|”
“|122|Rotator aux relay command not supported||”
“|123|Invalid rotator set command|X| ”
“|124|Invalid rotator command|X|”
Temperatures: A number in Celsius degrees, for ex: 23.3000
Relative humidity: An integer, for ex: 45
For xml formatted replies the Mime type “text/xml” is used.
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<carheaters>
<carheater>
<name>[Name of first heater]</name>
<relay>[Used Relay]</relay>
<temperature>[Current temperature]</temperature>
<relaystate>[0=Off, 1=On, X=Unknown]</relaystate> <!– Added in version 3.0 –>
<tempunit>Celsius/Fahrnheit</tempunit> <!– Added in version 3.0 –>
<engagetime>
<hour>[Hour for engage time in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for engage time in format 0-59 or 255 if N/A]</minute>
</engagetime>
<disengagetime>
<hour>[Hour for disengage time in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for disengage time in format 0-59 or 255 if N/A]</minute>
</disengagetime>
<tomorrowsdeparturetime>
<hour>[Hour for tomorrow’s departure time in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for tomorrow’s departure time in format 0-59 or 255 if N/A]</minute>
</tomorrowsdeparturetime>
<override>
<mode>[Override mode, one of: disabled, on, off, today or tomorrow]</mode>
<hour>[Hour for override time if mode today or tomorrow in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for override time if mode today or tomorrow in format 0-59 or 255 if N/A]</minute>
</override>
</carheater>
<carheater>
<name>[Name of second heater]</name>
<relay>[Used Relay]</relay>
<temperature>[Current temperature]</temperature>
<engagetime>
<hour>[Hour for engage time in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for engage time in format 0-59 or 255 if N/A]</minute>
</engagetime>
<disengagetime>
<hour>[Hour for disengage time in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for disengage time in format 0-59 or 255 if N/A]</minute>
</disengagetime>
<tomorrowsdeparturetime>
<hour>[Hour for tomorrow’s departure time in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for tomorrow’s departure time in format 0-59 or 255 if N/A]</minute>
</tomorrowsdeparturetime>
<override>
<mode>[Override mode, one of: disabled, on, off, today or tomorrow]</mode>
<hour>[Hour for override time if mode today or tomorrow in format 0-23 or 255 if N/A]</hour>
<minute>[Minute for override time if mode today or tomorrow in format 0-59 or 255 if N/A]</minute>
</override>
</carheater>
</carheaters>
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<carheaters>
<carheater>
<name>Car Warm Up 1</name>
<relay>CH 1</relay>
<temperature>23.6875</temperature>
<engagetime>
<hour>255</hour>
<minute>255</minute>
</engagetime>
<disengagetime>
<hour>255</hour>
<minute>255</minute>
</disengagetime>
<tomorrowsdeparturetime>
<hour>8</hour>
<minute>7</minute>
</tomorrowsdeparturetime>
<override>
<mode>disabled</mode>
<hour>255</hour>
<minute>255</minute>
</override>
</carheater>
<carheater>
<name>Car Warm Up 2</name>
<relay>Nexa 6</relay>
<temperature>23.6875</temperature>
<engagetime>
<hour>8</hour>
<minute>20</minute>
</engagetime>
<disengagetime>
<hour>9</hour>
<minute>35</minute>
</disengagetime>
<tomorrowsdeparturetime>
<hour>9</hour>
<minute>5</minute>
</tomorrowsdeparturetime>
<override>
<mode>disabled</mode>
<hour>255</hour>
<minute>255</minute>
</override>
</carheater>
</carheaters>
For xml formatted replies the Mime type “text/xml” is used.
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<acp>
<programs>
<program>
<no>[Program number]</no>
<name>[Program name]</name>
<relayname>[Relay used by the program]</relayname>
<relaystate>[Current relay state]</relaystate>
<override>
<mode>[Override mode]</mode>
<time>[Omitted, override time]</time>
</override>
</program>
<program>
<no>[Program number]</no>
<name>[Program name]</name>
<relayname>[Relay used by the program]</relayname>
<relaystate>[Current relay state]</relaystate>
<override>
<mode>[Override mode]</mode>
<time>
<hour>[Override hour]</hour>
<min>[Override minute]</min>
</time>
</override>
</program>
</programs>
</acp>
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<acp>
<programs>
<program>
<no>1</no>
<name>Light control</name>
<relayname>light</relayname>
<relaystate>0</relaystate>
<override>
<mode>disabled</mode>
<time></time>
</override>
</program>
<program>
<no>2</no>
<name>Heat control</name>
<relayname>heat</relayname>
<relaystate>1</relaystate>
<override>
<mode>on</mode>
<time></time>
</override>
</program>
<program>
<no>3</no>
<name>Fan control</name>
<relayname>fan</relayname>
<relaystate>0</relaystate>
<override>
<mode>off</mode>
<time>
<hour>14</hour>
<min>10</min>
</time>
</override>
</program>
</programs>
</acp>
Format of reply for command /acpstate/get2:
The format is the same as for /acpstate/get with the addition of this field:
<state>[Program state]</state>
which is repeated for every program.
[Program state] = 0 = program is disabled.
[Program state] = 1 = program is enabled.
Format of reply for command /rotatorcontrol/get/setup:
For xml formatted replies the Mime type “text/xml” is used.
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<rotor>
<presets>
<pre>
<no>[Number}</no>
<text>[Text]</text>
<deg>[Degree]</deg>
<active>[Active]</active>
</pre>
</presets>
<aux>[Aux relay mode]</aux>
<pwr>[Power relay mode]</pwr>
<type>[Rotator type]</type>
</rotor>
There will be 0-8 <pre> tags. Presets without texts are skipped.
[Active] will be 0 or 1.
[Aux relay mode] will be 0,1 or 2. 0=Off, 1=On, 2=Not supported.
[Power relay mode] will be 0,1 or 2. 0=Off, 1=On, 2=Not supported.
[Rotator type] will be a number according to the following list:
0=Analogue.
1=Prosistel D.
2=Array switch.
3=Green Heron RT21.
4=DCU 1.
5=Yaesu GS232B.
6=Alfaspid RAK.
This dashboard project is for the following purposes:
1. Improving performance of the heaters on the batteries.
2. Reducing RFI from the solar panels.
3. Displaying status such as the Flexradio final transistors temperature.
Hardware is a Raspberry Pi 4 located at the remote site, connected over the LAN to Web relays.
Modbus
The flow first polls Modbus data from the solar controllers and in turn performs actions like closing relays. A Node Red flow polls the modbus, then converts the modbus floating point data to readable decimal, and finally, turns relays on and off. One feature is improving the battery heater operation by bypassing the thermostats as needed. Another feature is to reduce RFI by disconnecting the solar panels from the solar controllers when batteries are fully charged. The most difficult task so far has been converting the floating point data to decimal. That flow is what is discussed first.
Data from the modbus is in the format of IEEE 754 half precision 16 bit floating point Little Endian which is unreadable by humans. Many JavaScript functions are available to perform a conversion operation but they have all proved impossible to implement during this project. Thanks to chatGPT a solution was finally implemented that works. It took 7 iterations of chatGPT to develop a Node Red function node which produced the correct output and no errors. The successful node is shown below to get it down on paper for preservation.
It was a huge milestone to get the floating point conversion node working. Below is what the output of the big achievement looks like. The number is the actual voltage of the 24 volt battery as measured by the solar controller and processed by the Node Red flow.
It’s easy to confuse the use of the word “function”. To offer some clarity, the node above is a Node Red “function” node. Inside this function node is a JavaScript “function”. The JavaScript function is the first thing in the node. The JavaScript function is declared and defined, making it ready to be used. Next element is at the bottom and that is where the JavaScript function is called, data is passed to it, and the output is moved into the msg.payload object.
The Flow
The object is passed to the next Node Red node which is a debug node.
On the left above is the Modbus Read node, named Stras 88. It’s settings are shown below.
In the Server field above, the name is Stras 88 which indicates the location of the solar controller and the port number. It’s I.P. address is entered by clicking on the pencil icon on the right. The Address in the Address field is obtained from the Morningstar documentation. The FC field is always FC 3 when reading a holding register per the Modbus specifications.
A big project has begun. Onward to the next part, the outputs.
OUTPUTS
Microbit RemoteRig 1216H Webswitch relays will be used because they are already in place from an earlier project. See https://w0qlremotebase.wordpress.com/2021/05/01/noise-chase/.
These relays are currently wired up to remotely turn on and off the solar panels from the solar controllers manually. Despite mechanically working perfectly, turning on and off the relays manually did not happen. Too much work? Along came Node Red and this function can now be down automatically. First, the command set for the 1216H is available on the Webswitch website and also posted elsewhere in this journal: https://w0qlremotebase.wordpress.com/2023/02/12/microbit-remoterig-1216h-webswitch-command-set/
TESTING
In Node Red a node called EXEC can be used to execute a command. The command can use curl to send a web request over the internet to the 1216H, and the response will be the status of that request. In the flow below, an http request is encapsulated in a curl command in an exec node:
The configuration in the exec node is shown below, with a fake I.P. address. Enter your own here.
In the next chapter some nodes will be wired together in such a way as to turn off the solar panels when the battery is fully charged and RFI is occurring.
Step 1 is to do a modbus read of a solar controller looking for the High Voltage Disconnect (HVD) bit. Morningstar controllers have this feature when using Lithium batteries. When the HVD bit is positive, tell the 1216H to close a relay corresponding to that controller. The closure in turn opens a higher current relay and disconnects the panels. Boom. RFI stops.
(Preliminary – needs more testing )
As more clubs get remote bases a new demand has surfaced and that is tracking users’ activity. Luckily, tracking is a well matched skill of a recent programming language called Node Red. Node Red needs little actual coding skills, developed by IBM, targeting home automation and Internet of Things devices. Recently hams have adapted Node Red to automate ham radio equipment, especially Flexradio 6XXX series. In the last three years many dashboards have been written to automate radio control for contesters and remote bases, thank to Node Red. An excellent example comes from WO2X.
A local club has offered to it’s members the use of a Flexradio remotely since July, 2022 and and now wants to track it’s activity. Searching the Web for a tracking application has proved fruitless, as has networking with other clubs. The response has always been, “We’re looking for the same thing. If you find one, let us know.” Or, “Why don’t you develop one and give us a copy”.
So, we did. This project was developed with a lot of help from YouTubers like Steven Houser, Kyle Klein, Michael Walker, Dave de Coons, and many others, and the Web in general. Currently the project is deployed at a local club station and is being field tested for improvements or for bugs. Features include the following.
Steps to recreate this project for your own club’s use are below:
Here is a copy of the Flow used in this project. Import it to your Node Red. Open an import window and copy and paste everything below. Node Red Version 2.2.2 was used as the development platform. Feel free to modify the flow, of course.
[
{
“id”: “fa203948d0e6d9d0”,
“type”: “tab”,
“label”: “Flow 1”,
“disabled”: false,
“info”: “”,
“env”: []
},
{
“id”: “251fb659293c42f1”,
“type”: “flexradio-discovery”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“port”: “4992”,
“x”: 330,
“y”: 240,
“wires”: [
[
“8287e170289d500a”
]
]
},
{
“id”: “3f09eb82379ac711”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 0,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Radio”,
“format”: “{{msg.payload.nickname}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 910,
“y”: 200,
“wires”: []
},
{
“id”: “db9955fa27cf75d0”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 1,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Status”,
“format”: “{{msg.payload.status}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 910,
“y”: 260,
“wires”: []
},
{
“id”: “e7be831eddfaae4b”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 2,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client I.P.”,
“format”: “{{msg.payload.gui_client_ips}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 900,
“y”: 320,
“wires”: []
},
{
“id”: “fa301f57cad7d937”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 3,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Station”,
“format”: “{{msg.payload.gui_client_stations}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 890,
“y”: 360,
“wires”: []
},
{
“id”: “ed6cd3458551a577”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 4,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Host”,
“format”: “{{msg.payload.gui_client_hosts}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 890,
“y”: 420,
“wires”: []
},
{
“id”: “92f266ba0fe72027”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 5,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Program”,
“format”: “{{msg.payload.gui_client_programs}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 880,
“y”: 460,
“wires”: []
},
{
“id”: “e16b56205f6185a9”,
“type”: “ui_text”,
“z”: “fa203948d0e6d9d0”,
“group”: “b09e9ca25cf6b31d”,
“order”: 6,
“width”: 0,
“height”: 0,
“name”: “”,
“label”: “Client Handles”,
“format”: “{{msg.payload.gui_client_handles}}”,
“layout”: “row-spread”,
“className”: “”,
“x”: 880,
“y”: 500,
“wires”: []
},
{
“id”: “8287e170289d500a”,
“type”: “trigger”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“op1”: “”,
“op2”: “”,
“op1type”: “pay”,
“op2type”: “pay”,
“duration”: “10”,
“extend”: false,
“overrideDelay”: false,
“units”: “s”,
“reset”: “”,
“bytopic”: “all”,
“topic”: “topic”,
“outputs”: 1,
“x”: 330,
“y”: 340,
“wires”: [
[
“59718a62747b10aa”
]
]
},
{
“id”: “59718a62747b10aa”,
“type”: “rbe”,
“z”: “fa203948d0e6d9d0”,
“name”: “Filter: block all but changes”,
“func”: “rbe”,
“gap”: “”,
“start”: “”,
“inout”: “out”,
“septopics”: false,
“property”: “payload”,
“topi”: “topic”,
“x”: 400,
“y”: 420,
“wires”: [
[
“a2d9d4f4aa370116”,
“5ef3f2abc0776143”,
“d6d6658a8cc20e0f”,
“3f09eb82379ac711”,
“db9955fa27cf75d0”,
“e7be831eddfaae4b”,
“fa301f57cad7d937”,
“ed6cd3458551a577”,
“92f266ba0fe72027”,
“e16b56205f6185a9”,
“dca3db48af21a307”
]
]
},
{
“id”: “1d2574fc485d623f”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Stations”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_stations”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 580,
“wires”: [
[
“9c48e2830ef9d446”
]
]
},
{
“id”: “76a6532bc40dc4a6”,
“type”: “file”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“filename”: “/var/www/html/test.log”,
“appendNewline”: true,
“createDir”: false,
“overwriteFile”: “false”,
“encoding”: “none”,
“x”: 700,
“y”: 1020,
“wires”: [
[]
]
},
{
“id”: “6b1041bab320ca67”,
“type”: “moment”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“topic”: “”,
“input”: “”,
“inputType”: “msg”,
“inTz”: “America/Denver”,
“adjAmount”: 0,
“adjType”: “days”,
“adjDir”: “add”,
“format”: “”,
“locale”: “en-US”,
“output”: “”,
“outputType”: “msg”,
“outTz”: “America/Denver”,
“x”: 180,
“y”: 700,
“wires”: [
[
“bf431a5acd90b832”
]
]
},
{
“id”: “bdb049085cc97475”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Timestamp”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “”,
“tot”: “date”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 170,
“y”: 640,
“wires”: [
[
“6b1041bab320ca67”
]
]
},
{
“id”: “a2d9d4f4aa370116”,
“type”: “delay”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“pauseType”: “delay”,
“timeout”: “50”,
“timeoutUnits”: “milliseconds”,
“rate”: “1”,
“nbRateUnits”: “1”,
“rateUnits”: “second”,
“randomFirst”: “1”,
“randomLast”: “5”,
“randomUnits”: “seconds”,
“drop”: false,
“allowrate”: false,
“outputs”: 1,
“x”: 530,
“y”: 660,
“wires”: [
[
“1d2574fc485d623f”,
“8cd903664f096da0”,
“cfab0638431b3f19”,
“8cabe28af2d37e8c”,
“b6eccdc3bda00895”
]
]
},
{
“id”: “8cd903664f096da0”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Client I.P.”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_ips”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 620,
“wires”: [
[
“f46629eecd4972e9”
]
]
},
{
“id”: “cfab0638431b3f19”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Program”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_programs”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 700,
“wires”: [
[
“3b931ee1682dd15f”
]
]
},
{
“id”: “8cabe28af2d37e8c”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Handles”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_handles”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 720,
“y”: 740,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “0f4f8fc63bf77a90”,
“type”: “rbe”,
“z”: “fa203948d0e6d9d0”,
“name”: “Filter: nulls”,
“func”: “rbe”,
“gap”: “”,
“start”: “”,
“inout”: “out”,
“septopics”: false,
“property”: “payload”,
“topi”: “topic”,
“x”: 1170,
“y”: 720,
“wires”: [
[
“dbfa56fdd624c7e4”
]
]
},
{
“id”: “d6d6658a8cc20e0f”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “New line”,
“func”: “msg.payload = msg.payload + \”\n\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 420,
“y”: 700,
“wires”: [
[
“dbfa56fdd624c7e4”
]
]
},
{
“id”: “5ef3f2abc0776143”,
“type”: “delay”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“pauseType”: “delay”,
“timeout”: “25”,
“timeoutUnits”: “milliseconds”,
“rate”: “1”,
“nbRateUnits”: “1”,
“rateUnits”: “second”,
“randomFirst”: “1”,
“randomLast”: “5”,
“randomUnits”: “seconds”,
“drop”: false,
“allowrate”: false,
“outputs”: 1,
“x”: 190,
“y”: 580,
“wires”: [
[
“bdb049085cc97475”
]
]
},
{
“id”: “b6eccdc3bda00895”,
“type”: “change”,
“z”: “fa203948d0e6d9d0”,
“name”: “Host”,
“rules”: [
{
“t”: “set”,
“p”: “payload”,
“pt”: “msg”,
“to”: “payload.gui_client_hosts”,
“tot”: “msg”
}
],
“action”: “”,
“property”: “”,
“from”: “”,
“to”: “”,
“reg”: false,
“x”: 710,
“y”: 660,
“wires”: [
[
“accffad613c92103”
]
]
},
{
“id”: “f46629eecd4972e9”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 620,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “accffad613c92103”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 660,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “3b931ee1682dd15f”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 700,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “dbfa56fdd624c7e4”,
“type”: “csv”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“sep”: “,”,
“hdrin”: “”,
“hdrout”: “none”,
“multi”: “one”,
“ret”: “\n”,
“temp”: “”,
“skip”: “0”,
“strings”: true,
“include_empty_strings”: “”,
“include_null_values”: “”,
“x”: 690,
“y”: 960,
“wires”: [
[
“76a6532bc40dc4a6”
]
]
},
{
“id”: “9c48e2830ef9d446”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 880,
“y”: 580,
“wires”: [
[
“0f4f8fc63bf77a90”
]
]
},
{
“id”: “bf431a5acd90b832”,
“type”: “function”,
“z”: “fa203948d0e6d9d0”,
“name”: “Append comma”,
“func”: “msg.payload = msg.payload + \”,\”;\nreturn msg;”,
“outputs”: 1,
“noerr”: 0,
“initialize”: “”,
“finalize”: “”,
“libs”: [],
“x”: 440,
“y”: 820,
“wires”: [
[
“dbfa56fdd624c7e4”
]
]
},
{
“id”: “dca3db48af21a307”,
“type”: “debug”,
“z”: “fa203948d0e6d9d0”,
“name”: “”,
“active”: true,
“tosidebar”: true,
“console”: false,
“tostatus”: false,
“complete”: “false”,
“statusVal”: “”,
“statusType”: “auto”,
“x”: 1070,
“y”: 400,
“wires”: []
},
{
“id”: “b09e9ca25cf6b31d”,
“type”: “ui_group”,
“name”: “Discovery”,
“tab”: “0613cce6f287631c”,
“order”: 1,
“disp”: true,
“width”: “6”,
“collapse”: false,
“className”: “”
},
{
“id”: “0613cce6f287631c”,
“type”: “ui_tab”,
“name”: “FlexRadio Dashboard”,
“icon”: “dashboard”,
“disabled”: false,
“hidden”: false
}
]
For the 2021 160 meter season the DXCC country count only went up a few countries and stands now at 66. Slightly disappointing, plus something is arcing at 750 watts. It’s ok below 750 watts. Capacitors with larger spacing were purchased and installed.
This picture shows both capacitors connected in an omega match configuration. The antenna would not tune correctly at 1840 kHz but it does tune at 1500 kHz. Over the summer one more change had been made. The capacitors may be wired wrong. These are both butterfly caps but they got wired in parallel as if they are two independent caps. That will be corrected on the next trip. Meanwhile, Bill, N0CU, made an on site visit and provided great consultation. He also provided a link to a great video that added insight.
The video sent us back to the books. Reviewing Section 6.9, Using the Beam/Tower as a Low-Band Vertical, in ON4UN’s Low -Band DXing, Fifth Edition the author offers that the omega match might not be necessary in some cases. He suggested trying the gamma match, too. That is easy to try by just disconnecting the capacitor that goes to ground, on the left. Doing so produced a dip of 1.45 SWR at 1840 kHz, just what the goal is. Next, it’s time to test it out.
Early results: Using 80 watts on FT8, 8pm local time October 3, Pskreporter shows a spot as far away as Israel with a nice report of -18dB. Unfortunately the station was not on the air, only monitoring, and so no contact could be attempted.
The following morning at dawn luck was better. Australia showed up on FT8 and was worked with only a few repeat transmissions, still using 80 watts. This is a new country on 160 meter. Very promising.
The new system has not been tested yet at high power. That is next. After re-wiring the caps, that is.
The maximum transmission unit (MTU) is the largest size frame or packet — in bytes or octets (eight-bit bytes) — that can be transmitted across a data link. It is most used in reference to packet size on an Ethernet network using the Internet Protocol (IP). A deprecated term is “window size”. Default is 1500 which is too big for the remote station network. Symptoms are the radio shows up in the Smartlink window but a connection attempt times out.
At least two workarounds are possible which will have no effect on any other applications or users on the router. Which one you use is up to you. Either one works equally well. The first workaround is to change the settings in the main router for the home. Find the settings for MTU in the network configuration and change the MTU to 1438.
The second workaround uses the command line in the pc to do network shell routines. This routine can change the MTU on the PC. Open cmd with administrator permissions (run as administrator by right-clicking on cmd and clicking on “run as administrator”).
Enter these commands:
>netsh
>interface
>ipv4
>show int
Look for the line that shows the connection to the Internet and write down it’s name. An example is “Ethernet”. If you’re using wifi, it might say “Wi-Fi”. Observe the value in the MTU column. Is it 1500?
Enter the following command:
>set subinterface “Ethernet” mtu=1438 store=persistent
where “Ethernet” is the name obtained in one of the steps above.
An “ok” will be returned if these steps worked. To test, enter the following command:
>show int
The results returned will show the current MTU which should now be 1438.
Note that the magic number may be lower or higher than 1438. Experiment if 1438 doesn’t work.
To return to normal, close the cmd window.
Meshtastic is described as an off-grid text message project. The text messages travel entirely over a network consisting of LoRa devices connected in a mesh. What does “off-grid” mean in this context? It means the text messages use a network that has nothing to do with wifi or the Internet or cell phone service. Instead the messages are transported over a mesh network made up of multiple LoRa devices. The device that sends and displays the texts is a smartphone, connected by bluetooth to a LoRa device. The LoRa device is in turn part of a mesh network with other LoRa devices. Again, wifi, the Internet, or the cellular network are not involved. Bluetooth is used only to connect between the smartphone and the LoRa device. Thus the entire end-to-end text message is completed off the grid. Meshtastic is a firmware version that is installed on a LoRa device. One example of a LoRa device is a TTGO T-Beam, shown below. Meshtastic firmware has been installed.
What does LoRa and Meshtastic have to do with a remote station?
The answer to that question is, it can be used for station telemetry. That means temperature, voltage, and current can be texted back to the client automatically. The text messages can be generated by an Arduino microcontroller or a Raspberry Pi Pico microcomputer and fed into the Lora device. On the other hand the client can send texts that turn on relays or turn off relays. Equipment can be rebooted. Equipment can be turned on and off.
It is a plan to implement a Meshtastic system at the W0QL remote station once a Lora signal path is reliable.
Upon further study, it appears that the above scenario would work fine if the two endpoints were less than 2 miles a part. With distances of 35 miles it is not a solution. Meshtastic requires the mesh nodes, that is, the relays in the middle, to be under the control of the same operator as the end points. Given the t-beam units have a range of 2 miles, several nodes will be necessary as relays. The purchase cost, maintenance, and installation of multiple nodes may be a limiting factor to using Meshtastic. Moving on to similar technologies, would LoraWAN work?
Research on LoraWAN shows it needs a gateway to the Internet. Any gateway at the remote station site would be down if the Internet is down and therefore not usable at the very time it is needed most. Finding another gateway that is reachable out in the country is a challenge. Gateways require authorization and that’s where this technology is limited. So as of now there doesn’t seem to be a solution for telemetry monitoring over a 35-mile link that is within reason. Project is on hold.
Mike Walker at Flexradio introduced us to KMTronic. He uses this device in his remote station to simplify turning equipment on and off remotely over the web. The KMTronic has a built in web page providing a simple user interface. All that is needed is a web browser and the KMTronic’s i.p. address. Priced at less than $100, it is a great solution for remote station users.
At the W0QL remote station a KMTronic has been installed to provide two backdoor access functions. One is LAN isolation between the AT&T Mobile Hotspot and the main LAN. Four relay contacts are used to electrically bridge the two LAN’s, or to isolate them. The other four contacts are used to reset the BMS’s on the four battery banks. If a BMS has tripped, the KMTronic can be accessed over the Internet and the corresponding relay can be activated that will reset the BMS remotely. This saves a site visit.
How To Use
Internally the i.p. address of the KMTronic is 192.168.1.204. It can be reached remotely by any device on ZeroTier with a network id ending in ee4.
For product information see the KMTronic web site: https://www.kmtronic.com/all-products?product_id=113
A screen shot of the W0QL KMTronic as it is configured today:
Abstract: It has always been a goal to have “backdoor” remote access for troubleshooting. There are times when the primary Internet connection is down and normal access is not possible. It is those times when backdoor remote access saves the day. It could prevent a site visit, a trip to the site. These are the specific essential building blocks:
AT&T Mobile Hotspot
Raspberry Pi running ZeroTier, ipforward and iptables
Same subnet but separate ranges of i.p. addresses
Let’s get started: First, an explanatory overview. The hotspot provides Internet access over a different path by using the cellular data network. This specific hotspot costs $35 a month for unlimited data. T-Mobile’s $50 service would probably also work. Up and down bandwidth is 30 Mbps, even in the rural location. Luckily there is an AT&T cell tower not too far from the remote site. Not so lucky is the fact that the hotspot provides only a private i.p. address and not a public address so it cannot be reached from the outside world. Called “carrier grade NAT” or CGNAT, it is a heavy duty impenetrable firewall. Not to fear, however.
A great solution to the CGNAT problem is a product call ZeroTier which becomes the second detail of this project. ZeroTier is an application that runs on a computer behind a firewall and reaches out over the Internet to a software defined LAN. A software defined LAN is similar to the user side of a home router. Instead of the hardware connections like a home router uses, a software defined LAN does it all with algorithms and the Internet. Other computers running the same application and same credentials can reach the same software defined LAN and communicate as if they were all in the same office. For backdoor access one instance of the application is running on a computer at the remote site (a Raspberry Pi) and another instance is running on a computer (Windows 11 pc ) at the home location. Competing products exist and might also work, like Tailsscale, reverse TCP tunnelling, SoftEther, WireGuard and possibly others that do NAT traversal. ZeroTier has been the most comfortable and successful of the ones tried at this remote station.
How To Use
Any device anywhere worldwide on the same ZeroTier network can reach the LAN at the remote site. As this is written the network id ends in ee4. To reach the i3 NUC: Power is on the ‘Station’ circuit on the 4005i using port 82. The NUC i.p. on the LAN is 192.168.1.100. It can be reached using Remote Desktop Protocol. The Pi is at 192.168.1.204 and it can be reached with Putty. The KMTronic is at 192.168.1.204 and it can be reached with a browser. If the main LAN is down the only device that can be reached is the Pi. Other well known ports:
Pi .201
86 .205
88 .206
82 .207
83 .208
90 .209
89 .210
84 .211
85 .212
How To Set Up
Click on the Home Main link to visit ZeroTier.
Home Main
Follow the instructions on the ZeroTier web page to make an account and to create a network. Their free plan has all the features needed.
This brings us to the third detail, the Raspberry Pi computer.
A Raspberry Pi is fully capable of running the ZeroTier application and then some.
Shown above is a Raspberry Pi model 3 which is the model being used in this project. Follow the instructions on the ZeroTier web page to join the network created above. With a hotspot and a Pi running ZeroTier the hardware and some of the software to get into the site is complete but no connection has been made to the main LAN yet.
Each detail has involved challenges but probably the biggest challenge of all has been how to connect to and how to communicate with the existing LAN at the remote site. At this point there are two LAN’s, one providing a data link between the hotspot and the Pi and the other LAN providing communication for all the existing equipment. Connecting any two LAN’s requires a router, but not just any router. An ordinary home router will not do. Turns out the solution is simple and elegant thanks to the Linux operating system running on the Raspberry Pi. It can run a few built-in processes and perform the necessary router functions. A nice writeup of how to configure this routing function is published by the ZeroTier developers: “Route between ZeroTier and Physical Networks“
One of the essential processes is iptables:
sudo iptables -t nat -A POSTROUTING -o $PHY_IFACE -j MASQUERADE
sudo iptables -A FORWARD -i $PHY_IFACE -o $ZT_IFACE -m state –state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i $ZT_IFACE -o $PHY_IFACE -j ACCEPT
Another essential process is ipforwarding:
sudo sysctl -w net.ipv4.ip_forward=1
Edit /etc/sysctl.conf to uncomment net.ipv4.ip_forward. This enables forwarding at boot.
Next, take steps to avoid two devices having the same addresses on the combined LAN: On the hotspot, set the dhcp i.p. address range to the highest 50 addresses in the subnet, and make the subnet identical to the main LAN subnet. Turnoff DHCP on the hotspot. On the main LAN, set the router dhcp range to exclude the top 50 addresses and leave DHCP on.
A few items remain to polish the backdoor project. The whole idea is to be able to access the remote network at all times. There is no way to know what the source of the failure might be. It could be power down inside the remote station. In that case the backdoor needs to have it’s own power. For that reason, the hotspot and Pi have their own battery and solar panel separate from the rest. Considering the main LAN goes through a big ethernet switch and that switch could be down, the hotspot and Pi have their own switch. That small switch is also powered by the separate battery. Rebooting devices remotely is invaluable. Some devices, like computers, can be rebooted with software commands or they might need a hardware reset. Other devices, like BMS’s and EMC’s require a hardware reset. Relays wired to provide the hardware reset, controlled over the Internet through the backdoor can save a trip to the site. At this site relays are wired to short out the BMS’s (which is how they are reset if they have tripped). Another bank of relays is installed to reset the EMC’s if they lock up ( like they have been prone to do ). Almost all equipment has a method of being rebooted or reset remotely.
A successful backdoor access project provides a lot of comfort knowing the every day remote operation has tools for a better chance of recovery when something goes wrong.
Thoughts for future improvements – One improvement could be to move all the non-radio equipment to the secondary Internet connection, leaving the entire bandwidth of the main connection to the radio. That would be easy because the hardware connections are already in place. It would just be a matter of changing the i.p. settings on each piece of equipment to static with the gateway address of the secondary connection. A second idea is to combine the two Internet connections into what is called “dual-WAN” service. A product exists to do this easily (according to the sales literature). It is called Speedify and is worth checking out someday.
One additional thought. Use bridging instead of routing to see if bridging would pass the broadcast packets. What this means is the packets that advertise a service are being blocked (by the hotspot??) when using routing. It is possible bridging would fix this. The hotspot would not see the packet headers and thus not know any particular packet was a broadcast packet.
One more additional thought. Use iptables “mangle” to create a mangle table which will be a MSS filter. Set the filter size to, in turn, create an MTU size that will pass through the PPPoE Internet connection at the radio end.
Here is an example of a line of code to create the mangle table:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
Credit for this example goes to serverfault.com
https://serverfault.com/questions/467756/what-is-the-mangle-table-in-iptables
W0QL - My Remote Base Journal 