smithtek-mako-rf 3.3.4 → 3.4.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,602 +1,225 @@
1
- **Installation**
2
- Install using the `NodeRED palette manager`
3
-
4
-
5
- ** Smithtek Mako RF Nodes**
6
-
7
- The Smithtek Mako RF nodes are designed specifically for the Mako PLC, while remaining fully compatible with other Modbus RTU devices connected over RS485.
8
-
9
- They support communication to one or multiple devices across hard-wired RS485 channels or long-range RF, all from a single, unified node. Whether you’re polling a single PLC or managing a full remote site, the node handles device sequencing and bus control automatically.
10
-
11
- Built for industrial environments, the node includes integrated queue management, retry handling, timeout control, gap spacing, and automatic reconnection logic. These features provide stable, predictable polling without requiring complex flow logic.
12
-
13
- The Smithtek Mako RF node effectively replaces the traditional Modbus contrib nodes and the separate Mako decoder node, combining communication and decoding into a single streamlined tool.
14
-
15
- One node. One inject. Full control.
16
-
17
-
18
-
19
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%201.png?raw=true)
20
-
21
- The Smithtek Mako RF node operates in two modes:
22
- Read Mode – Poll slave devices and retrieve data from registers.
23
- Write Mode – Send commands or values to slave devices.
24
- The PassPort Gateway provides three communication channels:
25
- RS485-1
26
- RS485-2
27
- Long Range RF
28
- You can assign any node to any bus channel, allowing wired and RF devices to operate independently while the node manages sequencing and communication control in the background.
29
-
30
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%202.png?raw=true)
31
- ---
32
-
33
- ## Bus Configuration
34
-
35
- Select the communication channel:
36
- - **RS485-1** → /dev/ttyAMA0
37
- - **RS485-2** → /dev/ttyAMA1
38
- - **RF** → Long range LoRa radio link
39
- When RF is selected, serial parameters are automatically managed.
40
- Timeout, Retries and Gap are configured in **seconds**.
41
-
42
- ---
43
-
44
- ## Mode
45
-
46
- ### Read
47
- Polls registers from the remote Mako and outputs structured JSON.
48
-
49
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%203.png?raw=true)
50
- ---
51
-
52
-
53
-
54
-
55
- ### Write
56
- Sends values to the remote device using:
57
-
58
- - FC5 – Write Single Coil
59
- - FC6 – Write Single Register
60
- - FC15 – Write Multiple Coils
61
- - FC16 – Write Multiple Registers
62
-
63
- Values can come from `msg.payload` or be fixed in the node configuration.
64
-
65
- Polls registers from the remote Mako and outputs structured JSON.
66
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Smithtek%20Mako%20RF%20Nodes%20page%204.png?raw=true)
67
-
68
-
69
- ---
70
-
71
- ## Device ID
72
-
73
- The Modbus Unit ID of the remote Mako (1–247).
74
- Must match the ID configured in the target device.
75
-
76
- ---
77
-
78
- ## Function Code
79
-
80
- Must match the table type configured in your V-NET program:
81
-
82
- - Read Coils
83
- - Read Digital Inputs
84
- - Read Holding Registers
85
- - Read Input Registers
86
-
87
- ---
88
-
89
- ## Address
90
-
91
- Starting Modbus register address.
92
- Must align exactly with the Modbus table built in your Mako V-NET program.
93
-
94
- ---
95
-
96
- ## Quantity
97
-
98
- Total number of registers to read.
99
-
100
- - 16 bit value = 1 register
101
- - 32 bit value = 2 registers
102
-
103
- **Example:**
104
- 3 × 32 bit floats = Quantity 6
105
-
106
- Quantity must cover all registers defined in your decoder map.
107
-
108
- ---
109
-
110
- ## Decoder Map
111
-
112
- Build the register table in the exact same order as your Mako V-NET Modbus table.
113
- Each row defines how raw Modbus data is converted into structured JSON.
114
-
115
- ### Name
116
- Becomes the output key in `msg.payload`. The name could be your sensor name like "level sensor" or " thermal trip" " pump control" choose a name that suits your SCADA scheme.
117
-
118
- ### Prefix
119
-
120
- The Prefix field applies to every name in the decoder table. Enter `b1` and a row named `Pressure` becomes `b1 Pressure` in `msg.payload`, with a space between the prefix and name.
121
-
122
- Copy the node and change only the prefix to reuse the same table for another asset. Leave it blank to use the table names as entered.
123
-
124
- ### Register Data Type
125
-
126
- - 16 bit integer
127
- - 16 bit unsigned
128
- - 32 bit integer
129
- - 32 bit unsigned
130
- - 32 bit float
131
- - Digital to unsigned binary encoder
132
-
133
- ### Offset (regs)
134
-
135
- Offset is configured in registers.
136
- Automatic stepping behaviour:
137
- - 16 bit types increase by 1 register
138
- - 32 bit types increase by 2 registers
139
- - Digital encoder increases bit number from 0–15 before moving to the next register
140
-
141
- Offsets must match your V-NET Modbus table layout exactly.
142
-
143
- ---
144
-
145
- ## Digital to Unsigned Binary Encoder
146
-
147
- Used when one 16 bit register contains multiple digital states.
148
- The Bit column becomes active.
149
- Bit automatically increments when adding rows.
150
- After Bit 15, the next row moves to the next register.
151
-
152
- ---
153
-
154
- ## Scale
155
-
156
- Optional value transformation applied after the Modbus register is read.
157
-
158
- Decoded numeric readings are rounded to a maximum of six decimal places after Math or Range scaling. Values remain numbers, without added trailing zeros. Very small values may round to zero. Raw data in `msg.modbus.raw` is unchanged.
159
- The Scale field lets you adjust raw register data into meaningful engineering values without needing extra function nodes. Think of it as lightweight post-processing built directly into the driver.
160
-
161
- Choose a scaling mode for each row:
162
-
163
- - **None** leaves the value unchanged.
164
- - **Math** applies an operator and number, such as `/100` or `+5`.
165
- - **Range** maps input low/high values to output low/high values.
166
-
167
- All controls stay on the same row. Selecting None disables the calculation while keeping the entered settings for reuse.
168
-
169
- ### Math
170
-
171
- You can apply the following operators:
172
-
173
- - Addition +
174
- Adds a number to the value.
175
- Example:
176
- +10 → adds 10 to the parsed value
177
-
178
- - Subtraction -
179
- Subtracts a number from the value.
180
- Example:
181
- -5 → subtracts 5 from the parsed value
182
-
183
- - Multiply *
184
- Multiplies the value by a number.
185
- Example:
186
- *10 → multiplies the parsed value by 10
187
-
188
- - Divide /
189
- Divides the value by a number.
190
- Example:
191
- /100 → divides the parsed value by 100
192
-
193
- - Modulus %
194
- Returns the remainder after division.
195
- Example:
196
- %10 → returns remainder when value is divided by 10
197
-
198
- If you want to multiple your modbus value by 10 you would put "* 10" without the quotes and use a space between the number and the match function.
199
-
200
- ### Range — 4–20 mA Scaling
201
-
202
- Select **Range** and enter **In low**, **In high**, **Out low** and **Out high**. This converts a sensor reading into engineering units in the Passport without a separate Function node or a calculation in the Mako.
203
-
204
- For a 4–20 mA signal representing 0–100%:
205
-
206
- | In low | In high | Out low | Out high |
207
- |---|---|---|---|
208
- | 4 | 20 | 0 | 100 |
209
-
210
- A reading of 4 becomes 0, 12 becomes 50, and 20 becomes 100.
211
-
212
- Use the values actually reported by the register. If it reports 4000–20000, enter 4000 and 20000 as the input limits instead of 4 and 20.
213
-
214
- Tick **Clamp** to keep the result within the output limits. Otherwise, values outside the input limits continue scaling beyond the output range. Input low and high must differ. Negative, decimal and reversed ranges are supported. Range applies to numeric values and replaces the Math calculation for that row.
215
-
216
- This allows you to convert raw Modbus numbers into readable, usable data straight from the node — reducing additional processing and keeping flows clean and simple.
217
-
218
- ---
219
-
220
- ## Output Behaviour
221
-
222
- ### Output Pins
223
-
224
- - **Top pin — Data / alarm:** sends parsed Modbus readings or write confirmations. If a request fails, it sends the friendly fault JSON for the cloud instead.
225
- - **Bottom pin — Debug:** sends technical error details for a local Debug node. Leave it disconnected if these details are not needed. Successful requests send nothing from this pin.
226
-
227
- ### Fault Messages
228
-
229
- Example payload from the top pin:
230
-
231
- ```json
232
- {"b1 RF ID1 Not communicating — check power/RF; disable if out of service":1}
233
- ```
234
-
235
- The fault name identifies the prefix, bus and device ID, followed by an operator message. If the prefix is blank, the node Name is used. Other problems, such as an unsupported register or invalid settings, receive a message appropriate to that fault.
236
-
237
- A timeout fault is sent after one poll exhausts its retries: retries set to 0 means one failed attempt; retries set to 2 means three failed attempts. A successful retry sends normal data only. An unsupported-register error is reported immediately because retrying cannot correct the address. Each failed poll sends a fault; a redeploy cancellation does not.
238
-
239
- The bottom pin carries `msg.payload.ok`, `msg.payload.error`, `msg.payload.code` and `msg.payload.req` for troubleshooting. Technical details are also available in `msg.modbus`. Node-RED error logs and Catch handling remain available.
240
-
241
- When communication succeeds again, the top pin resumes normal readings. No automatic zero/clear alarm is sent.
242
-
243
- ### Successful Read
244
-
245
- - `msg.payload` → Decoded structured JSON
246
- - `msg.modbus.raw` → Raw Modbus response
247
- - `msg.modbus.req` → Request metadata
248
-
249
- ### Successful Write
250
-
251
- - `msg.payload` → Device confirmation response
252
- - `msg.modbus.raw` → Raw Modbus confirmation
253
-
254
- The write response is the actual Modbus confirmation returned by the remote device.
255
-
256
- ---
257
-
258
- ## Industrial Behaviour
259
-
260
- - Single shared bus queue per channel
261
- - One request processed at a time
262
- - Timeout handled in seconds
263
- - Configurable retry attempts
264
- - Optional inter-request gap
265
-
266
- Designed for stable Modbus RTU polling over RS485 or long-range RF links.
267
-
268
- ---
269
- ## Decoder Mapping V-NET v NodeRED
270
-
271
-
272
- The Decoder Map in the Mako RF node must match your V-NET Modbus table exactly.
273
- Every register must appear in the same order in both tools.
274
- If the order does not match, the decoded values will be incorrect.
275
- Think of it as a mirror:
276
- V-NET defines the Modbus table.
277
- The Node-RED Decoder reads it back in the exact same sequence.
278
- Register type, size (16-bit or 32-bit), and position must align between both.
279
- Digital to Unsigned Binary Encoder
280
- When using Digital to Unsigned Binary Encoder in V-NET:
281
- A single 16-bit register holds up to 16 digital values
282
- Each digital output occupies one bit (0–15)
283
- In the Node-RED Decoder Map, you select the same register type
284
- Then assign the correct bit number for each digital
285
-
286
- Example:
287
-
288
- Bit 0 = Digital 1
289
- Bit 1 = Digital 2
290
- Up to Bit 15
291
- This allows one register to represent 16 individual digital states.
292
-
293
- Best Practice
294
- It is recommended to place Digital to Unsigned registers at the end of your Modbus table.
295
- This gives you flexibility to:
296
- Add new digital points later
297
- Adjust bit assignments
298
- Expand without shifting existing analog register positions
299
- Keeping digitals grouped at the end prevents breaking your existing register structure in future revisions.
300
-
301
- Correct mapping ensures clean decoding, predictable data, and stable long-term expansion.
302
-
303
- ## Example Configuration reading registers ##
304
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Decoder%20Map.png?raw=true)
305
-
306
-
307
-
308
- In the screen shot example above is a typical reading the Mako map/\ ,
309
-
310
- The V-NET screenshot shows on the left shows.
311
-
312
- Device ID: 1
313
- Start register: 0
314
- Modbus table type: Input Registers
315
- 2 × 32-bit floats
316
- 2 × 16-bit unsigned registers
317
-
318
- The second 16-bit unsigned register is used as a Digital to Unsigned Binary Encoder, allowing up to 16 digital values to be packed into a single register.
319
- On the Node-RED Mako RF node properties, you can see these settings match exactly:
320
- Device ID is set to 1
321
- Function Code matches Input Registers
322
- Start address is 0
323
- Quantity shows 16, this is higher than needed but a good habbit to do as it ensurs you dont miss a register. If we wanted to match it completely we would have this set to 6 length!
324
-
325
- Decoder Map mirrors the exact register order and types from V-NET
326
- In this example, RF is used as the communication interface on both the Mako PLC and the PassPort Gateway.
327
- Once deployed, each poll from the PassPort will correctly read the Mako Modbus table.
328
- The decoded data will then be output from the node, ready for use in dashboards, logic, or cloud transmission.
329
-
330
- ---
331
- ## Example Configuration writing a single coil register ##
332
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/decoder%20write%20to%20a%20coil.png?raw=true)
333
-
334
- In this example, an additional coil has been added to the V-NET Modbus map.
335
- The Node-RED Mako RF node is now set to Write mode, and the settings match the V-NET configuration:
336
- Device ID matches the Mako
337
- Function Code matches the coil type
338
- Address matches the coil register in V-NET
339
- Communication channel remains the same (RF or RS485)
340
- When triggered with an inject node:
341
- If using msg.payload, the value (true/false) will be written directly to the selected coil.
342
- If using Fixed, the configured value will be sent on every inject.
343
- Once deployed, each trigger will send a write command to the Mako, updating the coil state in real time.
344
-
345
- ---
346
- ## Example Configuration writing a single holding register ##
347
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/Decoder%20writing%20a%20single%20register.png?raw=true)
348
-
349
- In this example, a Holding Register has been added in the V-NET Modbus map at address 0.
350
- The Node-RED Mako RF node is set to Write mode, configured as:
351
- Device ID matches the Mako
352
- Function Code set to Write Single Register (FC6)
353
- Address set to 0 to match V-NET
354
- Communication channel matches the system (RF or RS485)
355
- When triggered:
356
- From msg.payload – the numeric value in the payload is written directly to the holding register.
357
- Fixed mode – the configured value is written on every inject.
358
- Once deployed, each inject sends the write command to the Mako, updating the holding register immediately. The value is then available inside the V-NET program just like any other mapped register.
359
-
360
-
361
- ---
362
- ## Node Status ##
363
-
364
- Each Mako RF node shows a live status under the node so you can see what it’s doing without opening debug panels. This is especially useful when polling multiple devices, troubleshooting timeouts, or confirming that queues are being processed correctly.
365
-
366
- What you’ll see
367
-
368
- `Idle / waiting`
369
- No active request is being processed. The node is ready for the next poll.
370
-
371
- `Polling (in progress)`
372
- Blue dot status while a request is being sent and a reply is expected.
373
- Typical text includes the bus name, function code, unit id, and address, for example:
374
- RF: fc4 uid1 @0 (try 1/3)
375
-
376
- `Success (response received)`
377
- Green dot status when the device responded correctly.
378
- Example:
379
- RF: ok fc4 uid1
380
-
381
- `Failure / timeout / comms fault`
382
- Red ring status when a request fails after retries or times out.
383
- Example:
384
- RF: fail fc4 uid1
385
- The reason will also be available in msg.modbus.error on the output message.
386
-
387
- `Queue activity (multiple devices)`
388
- When multiple polls are triggered together, the status will “walk” through each device one at a time as the queue processes. This is normal and confirms the node is sequencing requests rather than blasting the bus.
389
-
390
- ``Notes``
391
-
392
- The (try x/y) indicator shows retry behaviour. For example try 2/3 means the first attempt failed and it is retrying.
393
-
394
- If you see repeated red failures on a single device, it usually points to ID/address mismatch, wiring/RF link quality, or the poll rate being too aggressive for the link.
395
-
396
-
397
- ---
398
- ## RSSI (RF Signal Strength Diagnostic) ##
399
-
400
- RSSI (Received Signal Strength Indicator) provides a live measurement of the RF signal strength between the PassPort and the remote Mako device when using the RF channel.
401
-
402
- When enabled, the node performs an additional request to the LoRa module after each successful Modbus read. The returned signal strength (in dBm) is then appended to the output payload.
403
-
404
- This allows you to:
405
- - Verify RF link quality during installation
406
- - Diagnose weak or marginal radio paths
407
- - Confirm antenna alignment and placement
408
- - Monitor signal health during maintenance
409
- How to Enable
410
- - Open the Bus configuration node (smithtek-mako-rf-bus).
411
- - Select the RF channel.
412
- - Tick the RSSI checkbox.
413
- - Deploy.
414
- - To disable RSSI, simply untick the checkbox and deploy again.
415
-
416
-
417
- ## RSSI Output Behaviour (msg.payload) ##
418
-
419
- When enabled:
420
- RSSI is appended to the normal decoded payload (msg.payload).
421
- It is added to the same JSON object generated by the Decoder map.
422
- The property name is automatically derived from the node block name.
423
-
424
- `RSSI Guard & Timeout Settings`
425
-
426
- The RSSI feature includes two adjustable timing parameters to fine-tune how the LoRa module is queried after a Modbus poll.
427
- In most installations.
428
- `The default values (10ms guard / 100ms timeout) are ideal and do not require adjustment.
429
-
430
- `RSSI Guard (ms)`
431
-
432
- The RSSI Guard is the delay between the completed Modbus response and the RSSI request being sent to the LoRa module.
433
- - This short pause ensures:
434
- - The Modbus transaction has fully completed
435
- - The UART buffer has settled
436
- - The RF module is ready to respond cleanly
437
-
438
- Typical range: 5–10ms
439
- Default: 10ms
440
-
441
- Lower values may work, but 10ms provides stable behaviour across most installations.
442
-
443
- `RSSI Timeout (ms)`
444
-
445
- The RSSI Timeout defines how long the system will wait for the LoRa module to respond with the RSSI value before aborting the request.
446
- Default: 100ms
447
-
448
- This is usually more than sufficient. Increasing the timeout:
449
- Does not improve signal strength
450
- Only increases the wait time if the module does not respond
451
- The timeout should only be increased if diagnosing unusual behaviour on a slow or noisy link.
452
-
453
- ## RSSI Practical Guidance ##
454
-
455
- - Leave both values at default unless diagnosing an issue.
456
- - Use RSSI primarily during install or maintenance.
457
- - If RSSI is enabled permanently, keep guard low and timeout reasonable to avoid unnecessary bus slowdown.
458
-
459
- In short, the defaults are tuned for real-world PassPort + Mako RF deployments and will suit almost every scenario.
460
-
461
- ![SmithTek Control](https://github.com/smithtekIOT/ArtWork/blob/master/RSSI%20switch.png?raw=true)
462
-
463
-
464
- ---
465
- ## Polling Tips – Long Range RF ##
466
-
467
- RF polling is different to hard-wired RS485. Even though it still looks like Modbus, the request and reply must travel through the radio link and be processed at both ends. That adds “time of flight” and a bit of overhead, so the fastest possible poll rate is always slower than RS485.
468
-
469
- On the PassPort, the RF channel hides baud/parity/stop settings because the radio link is handled internally. What you control instead is the pacing: timeout, retries, gap, and your inject interval.
470
-
471
- ``What slows RF down``
472
-
473
- - Air link latency (packetising + radio turnaround)
474
- - Retries when the link is marginal
475
- - Bigger register reads (more bytes to move)
476
- - Polling too frequently, causing requests to stack up
477
- - Best practice for multiple Makos
478
- - Polling should be treated as a “cycle”: each device gets a turn, one at a time.
479
-
480
- Choose an inject interval that allows the whole device list to complete without building a backlog.
481
- If you trigger multiple devices at once (single inject feeding multiple RF nodes), the queue will serialize them.
482
-
483
- Cycle time rule (use this in your markdown)
484
-
485
- `Cycle time ≈ (N × (typical RF transaction time + gap_s)), plus a bit of margin.`
486
-
487
- ``Where:``
488
- - N = number of RF devices
489
- - typical RF transaction time = how long one poll normally takes (including reply)
490
- - gap_s = the deliberate spacing you set between requests
491
-
492
- ## Practical tuning tips ##
493
-
494
- - Start conservative: increase speed only after you’ve proven stability.
495
-
496
- - If you see timeouts, the first fix is usually: slow the cycle down (longer inject interval), not bigger timeouts.
497
-
498
- - Keep read sizes sensible. Large reads are fine, but they raise transaction time, so the cycle must be longer.
499
- - For RF, it’s usually better to have one inject per site (simple) but set the inject interval long enough that the queue clears every cycle.
500
-
501
- - If you want “no backlog ever”, do not inject faster than the cycle time, otherwise requests will pile up behind the queue and devices will start timing out.
502
- ---
503
-
504
- ## RF Polling Guide (≈100 Bytes Per Device) ##
505
-
506
- | RF Devices | Typical Per-Device Time (s) | Recommended Gap (s) | Safe Cycle Time (s) | Recommended Inject Interval |
507
- |------------|----------------------------|---------------------|---------------------|-----------------------------|
508
- | 1 | 1.5 | 0.5–1.0 | ~2–3 | 3 seconds |
509
- | 2 | 1.5 | 0.5–1.0 | ~4–5 | 6 seconds |
510
- | 3 | 1.5 | 0.5–1.0 | ~6–7 | 8–10 seconds |
511
- | 4 | 1.5 | 0.5–1.0 | ~8–10 | 12 seconds |
512
- | 5 | 1.5 | 0.5–1.0 | ~10–12 | 15 seconds |
513
- | 6 | 1.5 | 0.5–1.0 | ~12–15 | 18 seconds |
514
- | 7 | 1.5 | 0.5–1.0 | ~15–18 | 20 seconds |
515
- | 8 | 1.5 | 0.5–1.0 | ~18–21 | 25 seconds |
516
- | 9 | 1.5 | 0.5–1.0 | ~20–24 | 30 seconds |
517
- | 10 | 1.5 | 0.5–1.0 | ~22–26 | 30–35 seconds |
518
-
519
- `Important notes read below `
520
-
521
- ## RF Spreading Factor Note ##
522
-
523
- The above table is based on the default spreading factor of 1024.
524
-
525
- At this setting, the transaction times shown are realistic for stable industrial polling with approximately 100 bytes per device.
526
- If you increase the spreading factor for longer range transmission, the air time increases significantly.
527
- As a simple rule:
528
- Add at least 2 seconds per spreading step increase
529
-
530
- Maximum spreading factor supported is 4096
531
-
532
- Example:
533
-
534
- - 1024 → use table values
535
-
536
- - 2048 → add ~2 seconds to the recommended inject interval
537
-
538
- - 4096 → add ~4 seconds to the recommended inject interval
539
-
540
- Increasing spreading improves range and link robustness, but it reduces throughput. Always adjust your inject interval to suit the radio configuration to avoid queue build-up and timeouts.
541
-
542
- In RF systems, range and stability always win over speed.
543
-
544
- ---
545
- # Troubleshooting Guide – Smithtek Mako RF Node
546
-
547
- | Issue / Symptom | Possible Cause | Recommended Action |
548
- |-----------------|---------------|--------------------|
549
- | Red status: `fail fcX uidY` | Device ID mismatch | Confirm Device ID in Node-RED matches V-NET configuration |
550
- | Red status: timeout | Polling too fast | Increase inject interval (slow the cycle time) |
551
- | Red status: timeout | RF link marginal | Increase spreading factor or improve antenna alignment |
552
- | Red status: timeout | Inject interval shorter than cycle time | Ensure inject interval is longer than full device cycle |
553
- | Red status: timeout after working normally | Bus overloaded | Reduce number of devices per cycle or increase interval |
554
- | Only first and last device polling | Queue dropping logic enabled | Disable aggressive queue dropping or increase maxQueue |
555
- | Devices poll intermittently | Retries too high | Reduce retries to prevent blocking the queue |
556
- | Devices stop polling after deploy | Serial port locked | Restart Node-RED or power cycle PassPort |
557
- | Data values incorrect | Register order mismatch | Ensure V-NET Modbus table matches Node-RED decoder map exactly |
558
- | 32-bit values incorrect | Wrong word order | Confirm correct 32-bit interpretation (float / unsigned / integer) |
559
- | Digital bits incorrect | Bit index mismatch | Ensure correct bit number (0–15) selected in decoder |
560
- | Write command not working | Wrong function code | Confirm FC5 for coil, FC6 for single register, FC15/16 for multiples |
561
- | Write works but value wrong | Payload type mismatch | Ensure msg.payload is correct type (bool or number) |
562
- | Write command appears successful but nothing changes | Writing to wrong register type | Confirm coil vs holding register mapping in V-NET |
563
- | Queue growing continuously | Inject too fast | Increase inject interval |
564
- | Random comms drops on RF | Spreading factor too low for range | Increase spreading factor (add time to cycle) |
565
- | RF very slow but stable | High spreading factor | Increase inject interval accordingly |
566
- | Works on RS485 but not RF | Wrong Bus selected | Confirm correct Bus channel assigned |
567
- | RS485 unstable | Wiring issue | Check termination resistors and polarity (A/B swapped) |
568
- | All devices fail at once | Bus configuration changed | Confirm baud rate, parity, stop bits match |
569
- | Node shows “bus config missing” | Config node deleted | Reassign or recreate the Bus config |
570
- | Node invisible / unknown type | HTML/JS syntax error | Check node installtion, reinstall or contact smithtek support |
571
-
572
- ## Golden Rule
573
-
574
- Always make your inject interval longer than your full device cycle time.
575
-
576
- Cycle time ≈ (Number of devices × transaction time + gap).
577
-
578
- If the inject interval is shorter than the cycle time, the queue will grow, timeouts will occur, and stability will suffer.
579
-
580
- Slow and stable always beats fast and failing.
581
-
582
-
583
-
584
-
585
-
586
-
587
-
588
- ---
589
- # License
590
- Copyright (c) 2023 www.smithtek.com.au Licenced under the terms of the GPLv3
591
- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
592
- AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
593
- THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
594
- ARE DISCLAIMED. IN NO EVENT SHALL DAMIEN CLARK BE LIABLE FOR ANY DIRECT,
595
- INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
596
- BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
597
- DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
598
- OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
599
- NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
600
- EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
601
-
602
- www.smithtek.com.au
1
+ # Smithtek Mako RF and PassPort Connect
2
+
3
+ Node-RED nodes for communicating with Smithtek Mako and Solaris PLCs from a PassPort.
4
+
5
+ ## Included nodes
6
+
7
+ - **PassPort Connect (PPC)** is Smithtek’s proprietary communication link between PassPort, Mako and Solaris. It reads measurements and writes controls using the matching table created in V-NET2. Supports RF and RS485, plus USB for Mako.
8
+ - **Original Mako RF** provides basic Modbus communication and remains available for existing flows. Its settings and message formats are described in the [original Mako RF guide](https://github.com/smithtekIOT/makorf/blob/main/MAKO-RF.md). Use that guide when working with the original node.
9
+
10
+ ## Install
11
+
12
+ In Node-RED, open the menu, choose **Manage palette**, open **Install**, search for **smithtek-mako-rf**, and install it. If it is already installed, use the available update. Restart Node-RED if requested. The package includes both the original Mako RF node and the new **PassPort Connect** node.
13
+
14
+ Before updating an existing installation, export a backup of your flows. After installation, check that **PassPort Connect** appears in the Node-RED palette before importing your V-NET2 export.
15
+
16
+ ## Which guide should I use?
17
+
18
+ For a new V-NET2 PassPort Connect project, follow the instructions below. A separate copy is available in [PassPort Connect setup and everyday use](https://github.com/smithtekIOT/makorf/blob/main/PASSPORT-CONNECT.md). For an existing original Mako RF flow, use the [original Mako RF instructions](https://github.com/smithtekIOT/makorf/blob/main/MAKO-RF.md). The two nodes use different message formats.
19
+
20
+ ## PassPort Connect · setup and everyday use
21
+
22
+ PassPort Connect (PPC) is Smithtek’s proprietary communication link between PassPort, Mako and Solaris. It lets your PassPort read measurements and send commands to a Mako or Solaris. For example, you can check a tank level, change a setting or start a pump.
23
+
24
+ The smithtek-mako-rf package includes two communication nodes. Original Mako RF is for basic Modbus reads and writes. PassPort Connect is for the matching PassPort Connect table in V-NET2. Choose PassPort Connect for this guide; the two nodes use different message formats.
25
+
26
+ In V-NET2, use the PassPort Connect logic block to choose the readings and controls you want to share. Export from that logic block to create matching Read and Write nodes in Node-RED. Read means “tell me the values”; Write means “change this value”.
27
+
28
+ ### Setup
29
+
30
+ 1. In V-NET2, click New project in the top toolbar. Enter a project name, choose Mako or Solaris, then create the project. Save any existing work you want to keep.
31
+ 2. In the logic-block library on the right of V-NET2, open Communication and click PassPort Connect. Read the introduction, then click Add PassPort Connect to place the logic block on your diagram.
32
+ 3. Click the PassPort Connect logic block on your V-NET2 diagram. In its Properties panel on the left, enter a Unit ID from 1 to 247. Give every PLC sharing a PassPort connection a different Unit ID. Set Connections to the number of communication links this logic block will use.
33
+ 4. In that same Properties panel, click Edit Analog & Digital table. Add a row for each reading or control, enter a clear name such as Tank level or Pump start, and choose its value type and starting value. Click Apply table to save the table to the logic block.
34
+ 5. On the V-NET2 diagram, wire each measurement to its named input on the left of the PassPort Connect logic block. Wire each control from its named output on the right to the equipment output or logic block it should operate.
35
+ 6. Select the PassPort Connect logic block again. In its left-hand Properties panel, click PassPort Connect · export nodes. This opens the connection and export window.
36
+ 7. In that window, under Match the connections, choose the communication port used on your Mako or Solaris and the port used on your PassPort. For example, choose RF on both sides for radio, or Solaris RS485 and PassPort RS485-1 for a wired link. Open Review or change settings before export and check the settings for your chosen connection.
37
+ 8. In the same window, click Export read & write nodes. Choose a filename and folder, then save. V-NET2 creates the Node-RED JSON file and adds any missing Send and Receive wires to the selected PLC port on your diagram. Existing wires are kept. Apply settings is available if you want to save these connection choices without exporting a file.
38
+ 9. Back in V-NET2, save the project using Save in the toolbar. When ready, use Build program to build and upload it to the selected PLC. The export file alone does not update the PLC. If using RF, also set the PassPort radio to match the PLC.
39
+ 10. In Node-RED, open the flow page where you want the nodes. Open the menu, choose Import, select the JSON file saved by V-NET2 and choose Current flow. Click Import and place the Read and Write nodes on that page. Do not paste this JSON into an existing node’s settings.
40
+ 11. In Node-RED, double-click each imported node to check its Action, Unit ID and Connection. Add an Inject node before Read and connect a Debug node to each output. Leave Inject once after startup and Repeat off for this first test. Click Deploy, then press the Inject button to read the PLC.
41
+
42
+ ### 1 · Choose your connection
43
+
44
+ | Connection | How to connect |
45
+ | --- | --- |
46
+ | RF · Mako or Solaris | Choose RF at both ends. Match the frequency, range and Network ID on the PLC and PassPort. If you use an encryption key, match that too. |
47
+ | RS485 · Mako | Choose RS485-1 or RS485-2 on the Mako and the wired port you are using on PassPort. Connect A to A and B to B. Match the baud rate and serial format at both ends. |
48
+ | RS485 · Solaris | Choose RS485 for Solaris and RS485-1 or RS485-2 for PassPort. Connect A to A and B to B. Set the Solaris serial switch to RS485. It uses the shared Monitor / RS485 Send and Receive pins. Match the baud rate and serial format at both ends. |
49
+ | USB · Mako | Connect the Mako USB socket above RS485-1 to a PassPort USB slot with the specified USB-A to USB-A data cable. Choose USB in V-NET2. This uses the Mako Monitor Send and Receive pins. In Node-RED, USB · Auto detect finds a single connected USB serial device. If several are connected, use Refresh USB and choose your device in Connection. |
50
+
51
+ USB detection runs on the PassPort, where the cable is plugged in. It finds available USB connections; it cannot prove that a device is a Mako. Confirm the selected device and Unit ID with a test read before sending commands. With several devices connected, choose the right one rather than letting the software guess.
52
+
53
+ If no USB device is found, check power and the data cable, then refresh the list. Devices with a unique identity can be found again if their connection number changes. If a device has no unique identity, check the selection again after unplugging or restarting.
54
+
55
+ Solaris has one shared Monitor / RS485 port. In your V-NET2 diagram, if a sensor logic block already uses that port, choose RF for the PassPort Connect logic block. The same Send port cannot be connected to both the sensor logic block and the PassPort Connect logic block.
56
+
57
+ Changing the export settings does not change the PassPort radio. Set that separately. Short range and Long range are radio settings, not promises about how far a signal will travel.
58
+
59
+ Keep the selected connection for PassPort messages. Do not also send ordinary Monitor text over it: mixed messages can stop readings and commands from working.
60
+
61
+ ### 2 · Make your channel table
62
+
63
+ | Choice | When to use it |
64
+ | --- | --- |
65
+ | Float | A 32-bit floating-point number, such as 12.5 volts. Stores about seven significant digits. Large whole numbers can round: 123456789 becomes 123456792. Choose 32-bit unsigned or 32-bit signed when you need that whole number exactly. |
66
+ | 16-bit signed | Whole numbers from −32768 to 32767. |
67
+ | 16-bit unsigned | Whole numbers from 0 to 65535. |
68
+ | 32-bit signed | Whole numbers from −2147483648 to 2147483647. |
69
+ | 32-bit unsigned | Whole numbers from 0 to 4294967295. |
70
+ | Digital | On or off: true or false. Use this for switches and simple controls. |
71
+
72
+ An Analog row holds a number. A Digital row holds on or off. Mako supports up to 64 rows; Solaris supports up to 16, with space also needed for the rest of your program.
73
+
74
+ Use a different name for each row, up to 40 characters. Capital letters matter: Pump and pump are different names. The editor will tell you if a name cannot be used.
75
+
76
+ V-NET2 works out the table addresses for you. An address is simply where a value is kept. Leave these alone when using an exported table.
77
+
78
+ Keep the PLC table and both Node-RED tables the same. After changing a table in V-NET2, upload the changed PLC program and export fresh nodes. Replace the old nodes so you do not accidentally read or send commands twice.
79
+
80
+ Starting values apply when the PLC starts. They do not make Node-RED send a command. A signal wired into a row on the left can keep replacing a command sent from PassPort. Leave that input unwired for a remote-only control.
81
+
82
+ Use a separate feedback row when you need to know what actually happened. A Pump start command and a Pump running sensor tell you different things.
83
+
84
+ ### 3 · Read your measurements
85
+
86
+ A Read node waits until another node asks it to work. Connect an Inject node to its input and press the Inject button. Each press reads the whole table. The value inside the Inject message does not choose a channel.
87
+
88
+ To start, leave Repeat and Inject once after startup off. After a successful test, you can set Inject to repeat. Allow enough time for one reading to finish before asking again.
89
+
90
+ Connect a Debug node to the first output to see successful readings. Values are listed by their table names in msg.payload. For example, {"Level":12.5,"Pump":false} means the level is 12.5 and the Pump value is off.
91
+
92
+ The second output reports problems. If part of a read fails, the node reports an error instead of sending an incomplete set of readings.
93
+
94
+ The PLC may need several requests to return a table. Values are collected one after another, so they are not all measured at exactly the same moment.
95
+
96
+ Prefix helps you tell PLCs apart. Enter North Mako and a row called Level appears as North Mako Level in the readings. The row name used for commands is still Level.
97
+
98
+ For more detailed flows, msg.ts records when Node-RED finished the read. It is not the time the PLC measured each value. msg.channels holds the original, unscaled numbers and on/off values; msg.passport holds the result and progress details. Most everyday flows only need msg.payload.
99
+
100
+ ### 4 · Send a command
101
+
102
+ | Write input | How to use it |
103
+ | --- | --- |
104
+ | Single channel · easiest | Choose the row in Write channel. Send a number for Analog, or Boolean true / false for Digital. Only that row changes. |
105
+ | Named values | Send a JSON object such as {"Pump":true,"Setpoint":25}. Only the named rows change. Use the exact table names, without a read Prefix. |
106
+ | Mapped arrays · advanced | Use this only if your flow already works with lists of values. Send the matching mappingId and the full Analog or Digital list in table order. The Digital list is called switches. |
107
+
108
+ Open the Write node, choose Single channel, then choose the row you want to control. Exported writers initially select the first row, so always check this before connecting commands.
109
+
110
+ In Inject, choose number for a numeric setting or Boolean for an on/off command. Do not choose string: the text “true” is not the same as the Boolean value true. For several named values, choose JSON.
111
+
112
+ Analog commands must fit the row type. Whole-number rows need whole numbers. Digital accepts true and false, or 1 and 0. Send an ordinary number even for a 32-bit row; the node handles its size.
113
+
114
+ The first output confirms that the PLC answered the command. It does not prove a motor turned or a valve moved. Read a feedback sensor to check the equipment.
115
+
116
+ Commands are not automatically repeated after a failed reply. A PLC can receive a command even when its reply is lost. Check the equipment or read it back before repeating a start, reset or pulse command.
117
+
118
+ If you change several values together and a later part fails, earlier values may already have changed. Read the values back before deciding what to send next.
119
+
120
+ Do not connect Read straight into Write. That can turn every repeat reading into another command. Make separate buttons or control logic for the changes you intend.
121
+
122
+ For advanced list-based flows, move the unscaled msg.channels object into msg.payload before using it as a Mapped arrays command. A one-Analog, one-Digital table could use {"mappingId":"the matching table ID","analog":[25],"switches":[true]}. Keep each supplied list complete and in order. The table ID checks the message against the node; it does not check which program was uploaded to the PLC.
123
+
124
+ ### 5 · Short pulses, remote resets and lost communication
125
+
126
+ Pulse on write works like a quick button press. Turn it on for a Digital row in V-NET2. A command turns the output on briefly, then it turns off by itself. The default is 250 milliseconds, or a quarter of a second. You can choose 1 to 1000 milliseconds.
127
+
128
+ This is useful for remote resets or restarts. For example, connect a Reset pulse to the reset input of the equipment logic you want to restart. Connect it to the PLC Reset input only when you intend to restart the whole PLC. A PLC restart interrupts communication, so its reply may be lost.
129
+
130
+ Each accepted write triggers a pulse, even a repeated value or false. Send one true command for each intended press. Do not send a second false command to release it: that would trigger another pulse. Another command during a pulse extends it. Reading the row does not trigger it.
131
+
132
+ Pulse settings belong to the PLC program. Save and upload after changing them, then export matching nodes.
133
+
134
+ The communications watchdog is a way for your program to notice missing messages. Set Timeout to the number of seconds it should wait. Zero turns it off.
135
+
136
+ If no valid communication arrives for that whole time, Watchdog sends false once. It waits another full timeout before checking for recovery. It sends true once when recent communication has returned, or waits and checks again if it has not. It sends no startup command.
137
+
138
+ Choose the response by wiring Watchdog into your program. It does not stop a pump or clear other values by itself. Use regular reads if you rely on them to keep communication active; manual clicks leave gaps between messages.
139
+
140
+ ### 6 · Copy a node and adjust how readings look
141
+
142
+ A useful tip: copy and paste your complete Read node, then change the copy’s Action to Write. This copies the entire channel table and connection settings, so you do not have to work out the table again. Choose Single channel and select the row you want to control before using it.
143
+
144
+ The copy is independent. Later edits to one node do not change the other. Keep both tables matched to the uploaded PLC program.
145
+
146
+ Scaling changes how a reading is displayed. For example, Math /100 turns 1250 into 12.5. None leaves it unchanged. Math allows one simple operation, such as *2, /100, +5 or -7. Do not enter a long formula.
147
+
148
+ Range converts between two scales. For example, Input low 4 and Input high 20, with Output low 0 and Output high 100, turns a 4–20 reading into 0–100. Clamp keeps the displayed result inside that range. Without Clamp, readings outside the input range can produce results below or above the output range.
149
+
150
+ Hide range only folds the settings away; it does not turn scaling off. Choose None to stop scaling. Scaling is for Analog rows.
151
+
152
+ Scaling and Prefix change named readings only. They do not change the PLC or commands. If /100 displays a stored value of 1250 as 12.5, a Write command still needs 1250 to request that original value.
153
+
154
+ You normally do not need to edit addresses. If you do, they must match the PLC. Moving rows in Node-RED does not change their addresses. Exporting again from V-NET2 uses the V-NET2 table and does not keep separate edits made in Node-RED.
155
+
156
+ ### 7 · Sharing a connection and avoiding delays
157
+
158
+ PLCs using the same PassPort RF or wired port share one Connection setting. Select that existing Connection in each Read and Write node. Give each PLC its own Unit ID.
159
+
160
+ Think of the connection as a single lane: messages take turns. A long table or a PLC that does not answer can hold up the next message, including a command.
161
+
162
+ Timeout is how long PassPort waits for an answer. Read retries is how many extra times it tries a failed read. The exported defaults wait up to 8 seconds and allow 2 extra read attempts. Commands do not use these extra attempts.
163
+
164
+ A queue is a waiting list of messages. If you ask for readings too quickly, the list grows and replies get late. Slow down the Inject repeat rate and remove duplicate triggers if this happens.
165
+
166
+ Each Read or Write node can have up to 16 waiting messages. The shared connection also has a limit. Use a Catch node to show queue-full errors, as well as Debug on the second output for other problems.
167
+
168
+ Start with one PLC and manual reads. Add regular reads and other PLCs gradually, checking how long replies take. Signal conditions and the amount of information affect the speed.
169
+
170
+ Signal-strength options used by the older RF node do not add a signal-strength reading to PassPort Connect.
171
+
172
+ ### 8 · If something is not working
173
+
174
+ | Problem | What to try |
175
+ | --- | --- |
176
+ | Unknown node after import | Check that PassPort Connect is available in your Node-RED palette. If it is missing, ask your installer to update PassPort Connect. |
177
+ | No reading after Deploy | Press the Inject button. Deploy saves the flow; it does not ask for a reading. |
178
+ | No answer or timeout | Check power, cables, Unit ID and matching communication settings. Confirm you uploaded the intended PLC program. For USB, refresh the detected-device list and confirm your selection. |
179
+ | Numbers look wrong | Compare the table and value types with V-NET2. Check whether scaling has changed the displayed number. |
180
+ | A command is rejected | Check the selected row, spelling and value type. If using lists, check they match the whole current table. |
181
+ | A command changes back immediately | Look for a local signal or other logic that keeps writing to that row. |
182
+ | A command reports an error | Check the equipment and read the value back. The command may have arrived even if its reply did not. |
183
+ | Replies are slow or the queue is full | Read less often. Remove duplicate Inject timers and make sure nodes sharing a port use the same Connection. |
184
+
185
+ Connect Debug to the second output to see the error message. Add a Catch node for errors such as a full waiting list. Both can report the same problem, so avoid making two automatic responses to one fault.
186
+
187
+ The error details can show how many parts completed and whether a command may already have reached the PLC. Use that information before trying again.
188
+
189
+ A green completed status means the last request worked. It does not prove the PLC is still connected now. A screen showing old readings should also show when they were last updated.
190
+
191
+ Before using a new setup unattended, test the readings, commands and loss-of-communication response on your equipment.
192
+
193
+ ### 9 · Export and import into Node-RED
194
+
195
+ In V-NET2, click the PassPort Connect logic block on your diagram. In the left-hand Properties panel, click PassPort Connect · export nodes. Choose the connections in the window that opens, then click Export read & write nodes and save the JSON file.
196
+
197
+ In Node-RED, open the flow page you want to use. Open the menu and choose Import. Select the JSON file saved by V-NET2, choose Current flow, click Import and place the nodes. This adds complete Read and Write nodes with your table. It does not create a new flow tab.
198
+
199
+ You can also copy the contents of that JSON file and paste them into the text box in the Node-RED Import window. You must still click Import. Do not paste the complete file into a Read or Write node’s settings.
200
+
201
+ In Node-RED, double-click each imported node. Check Unit ID and Connection. If that PassPort port is already in use, choose the existing Connection. Click Done, add your Inject buttons and Debug nodes, then click Deploy.
202
+
203
+ The other button in the V-NET2 logic block’s Properties panel is Export connection setup JSON. It saves a reference copy of your table and settings. It does not create Node-RED nodes and cannot be imported as a flow or pasted into a node. Use PassPort Connect · export nodes when you want the Read and Write nodes.
204
+
205
+ Neither export uploads the PLC program or changes the PassPort radio. Save and upload the PLC project from V-NET2 separately.
206
+
207
+ If PassPort Connect is missing from the Node-RED palette, ask your installer to add or update it.
208
+
209
+ Older projects using the ordinary Modbus logic block still have their separate single-node export. Farming quick templates use the PassPort Connect logic block and export the complete Read and Write pair.
210
+
211
+ ### 10 · Try it: battery reading and a relay command
212
+
213
+ Create a test project for your PLC. Add PassPort Connect with Unit ID 7 and one connection. Add Battery as a Float Analog row, and TestRelay as a normal Digital row with Pulse on write off.
214
+
215
+ Wire Battery Voltage to Battery on the left. Wire TestRelay on the right to a spare Mako output or Solaris relay. Leave TestRelay on the left unwired. Use an output whose connected equipment is suitable for your test.
216
+
217
+ In PassPort Connect, choose RF or an available RS485 connection and match the settings. Export the Read and Write nodes. Save and upload the PLC program when ready.
218
+
219
+ In Node-RED, import into Current flow. Connect Inject to Read and Debug to both outputs. Deploy and press Inject. The result should include a Battery number and TestRelay as true or false.
220
+
221
+ Open Write, choose Single channel and select TestRelay. Do not leave Battery selected. Make one Inject with Boolean true and another with Boolean false. Leave automatic startup and Repeat off. Wire both to Write, Deploy, and test each button.
222
+
223
+ Check the relay itself or a feedback sensor, as well as the reply. For an Analog setpoint later, select that row and send a number in the original units.
224
+
225
+ For a ready-wired farm project, open Farmers quick templates. Choose the picture, enter a unique Unit ID and the required sensor settings, then choose Load & export Node-RED. The project uses PassPort Connect, includes battery voltage and exports the complete Read and Write pair onto your current flow.