Node-red-node-arduino not connecting to the configured Arduinos after update

Hardware
1

I have several Arduinos connected to a Raspberry PI 2. When I update node-red-node-arduino to the recent version 0.3.1 (which isn't that recent), the Nodes do not connect to the configured Arduinos anymore, once I restart node-red afterwards, as it requests me to do.

It seems to be somewhat working when only 1 Arduino is plugged in, but as soon as there are like 2 and you make a reboot or sometimes just a full deploy, it's not so sure anymore. Sometimes the nodes do connect to one Arduino, not necessarily the right one, but mostly they don't connect to any. If they do however, it seems some nodes connect to, for example Arduino present on /dev/tty/ACM1 . But others don't, although they are still configured to connect to the same one. Another problem is, that it isn't even that apparent.

If an input or output node displays connected, it sometimes doesn't work. If it displays disconnected, it sometimes does work anyway. Surprise. Usually it doesn't. Changing the config nodes may rarely cause some to work, but as soon as you hit deploy, others, which were tested to have worked before, suddenly won't work anymore or may connect to a wrong one.

If you flip a coin you'd have better chances.

It's interesting, that if I start with a blank flow and start adding nodes to it, each safely connects even to different Arduinos. But as the nodes become more and more it all of a sudden starts to go nuts. No clue why. While the configuration seemingly stays the same, it doesn't seem to persist between reboots or even node-red-restart anymore. Sometimes not even between full deploys. That never happens with the old version.

The nodes of the old version (0.0.18) I've used so far, always connected to the right Arduino, depending on which USB-Port they are plugged in on reboot. Also, they always safely connected to the configured pin, and applied a pullup or what have you. And if one is connected, it was always safe to assume, that the rest, configured to connect to the same, are connecting as well, and not just say so. I wonder if others have similar issues, and why the old version works, but was replaced.

When I attempted to update node-red, it seems like the new version of it, doesn't support the old node-red-node-arduino version anymore. The new version of node-red-node-arduino, shows the same behavior with the new node-red version also, so sadly that does not solve the problem. I'm still on v1.0.3 because of that.

If someone smarter than me could help me with it, I would much appreciate it!

I have about 220 Arduino GPIO pins in use for my node-red home automation on 4 Arduino Mega running Firmata connected to an Raspberry PI 2 via USB. This was working reliable for 2 years now, but because of that problem, I can't really update node-red anymore and I'd rather not change the hardware setup just for being update capable, if I can avoid it, you see.

grafik
grafik1551×1298 878 KB

I was desperate to get things working and after a lightning fried my automation, I found node-red and tucked it together quick and dirty and stupid me added stuff while I was on it... It never changed since, cause that crime is a bit of a space problem now.

2 Likes
2

I have exactly the same problems.
(And I know about many other people encountered these things during the last 8 month too...)

  • Dry-lightning destroyed my expensive house control system (Teletask) (Through the Wi-Fi antenna!)
  • Promised myself never buying anything expensive or Wifi-related thing again, will spend only few$ on SHIELDED hardware.
  • Bought all kinds of cheap relay boards and dmx led dimmers quickly.
  • Installed OpenHABian to a Raspberry Pi
  • Tried to attach MPC23017 GPIO extensions >> realized I2C works only 10-20cm
  • Tried to create I2C-tiny-USB adapters >> not reliable, freeze on Pi-restart, changing bus-number
  • Bought some cheap Arduino Nano board remakes, ($5) hoped it will be easy from now on....
  • Realized there is Node-RED. Yeaaaah !
  • Found the "help" page and learned about firmata / gpio node. Yeaaaah!

And had to realize at the end:

Firmata is NOT reliable to use in industrial environment!

I've opened a topic for this not a long ago. Now we are 2 to find a solution :wink:

At the end, you'll see a link to the new topic with 4 possible solution I'm working on...

3

But the old node version is working reliably, the response time for the inputs is more than fast enough for double clicks on a button and continuous dimming. I just can't update anymore, because the new version isn't working.

4

After updating everything, node-red-node-arduino, NR etc.
Did you also update the Arduinos with firmata >= 2.2?

1 Like
5

That proves my point: they can not be "auto-searched by serial".
Because /dev/tty/ACM1 can be any of the 3 UNOs.

That node, and firmata itself is basically created to handle only 1 board, and not multiple.
First it would need this enhancement.

6

I have them all on Standard Firmata v 2.5.8. Should I have used a specific one?

I figured out something interesting. Pins above pin number 53 don't work anymore! They did with the old version. I use the analog input pins (A0 - A15) as digital outputs (pin 54 - 69) , because they don't show that startup turn on behavior like the other pins. Those Relays turn on at 0 (Pin Low). I use them for my Blinds.

Once I removed these culprit nodes from all of my flows, things started to behave more like expected. Like nodes that say connected actually are, and they connect to the Arduinos depending on the USB Port where they are plugged in. So that appears to work then, but sadly not for all of them.

It seems that the nodes connect on one flow tab, then on the next one, but then somewhere in the middle this:

grafik
grafik1587×739 212 KB

If I reorder the flows and deploy and restart, same on another flow. I just can't figure out what causes this. It appears to be somewhat random each restart. It almost seems as if it starts to fail after a certain amount of node connections. Sometimes when I make a full deploy they all lose connection until I reboot. I'm going to try if I can get it to work on a new raspian card next.

7

Do you check the console log too? Are there any warnings / errors listed?

  1. open a terminal >
  2. type: $ node-red-restart
  3. type: $ node-red-log
    you may exit with Ctrl + C

I use free Bitvise client instead of putty to log in to my Pi. Much much easier to handle:

  • Up/down to repeat last command
  • right Click = copy/past!
  • copy files to / from with a multi-tab file explorer

kép
kép1154×363 65.7 KB

1 Like
8

Thanks for the tool tip! Yes there are some errors, but I don't know what to make of it.

(node:1667) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:1667) UnhandledPromiseRejectionWarning: TypeError: Cannot set property 'mode' of undefined
    at Firmata.pinMode (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:947:27)
    at doit (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:154:63)
    at Firmata.<anonymous> (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:194:62)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:326:22)
    at Firmata.ready (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:733:13)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:314:20)
    at 106 (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:293:11)
    at SerialPort.<anonymous> (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:640:15)
(node:1667) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:1667) UnhandledPromiseRejectionWarning: TypeError: Cannot set property 'mode' of undefined
    at Firmata.pinMode (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:947:27)
    at doit (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:82:63)
    at Firmata.<anonymous> (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:122:62)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:326:22)
    at Firmata.ready (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:733:13)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:314:20)
    at 106 (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:293:11)
    at SerialPort.<anonymous> (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:640:15)
(node:1667) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 3)

It seems to change after a restart.

(node:2136) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:2136) UnhandledPromiseRejectionWarning: TypeError: Cannot set property 'mode' of undefined
    at Firmata.pinMode (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:947:27)
    at doit (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:154:63)
    at Firmata.<anonymous> (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:194:62)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:326:22)
    at Firmata.ready (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:733:13)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:314:20)
    at 106 (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:293:11)
    at SerialPort.<anonymous> (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:640:15)
(node:2136) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:2136) UnhandledPromiseRejectionWarning: TypeError: Cannot set property 'mode' of undefined
    at Firmata.pinMode (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:947:27)
    at doit (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:154:63)
    at Firmata.<anonymous> (/home/openhabian/.node-red/node_modules/node-red-node-arduino/35-arduino.js:194:62)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:326:22)
    at Firmata.ready (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:733:13)
    at Object.onceWrapper (events.js:420:28)
    at Firmata.emit (events.js:314:20)
    at 106 (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:293:11)
    at SerialPort.<anonymous> (/home/openhabian/.node-red/node_modules/firmata-io/lib/firmata.js:640:15)
(node:2136) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 3)
9

I've just tried it myself.

  • Plugged in 2 Arduino Nano board via USB to my Pi,
  • Dropped an Arduino Node on the flow
  • pressed deploy...

It says "connecting..." forever, and same errors occur.
So it's not just "your flow".
That means this component is not very well written, and not up to date either.
These are the most important parts:

[DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated.

and
TypeError: Cannot set property 'mode' of undefined

I can not say there is a chance to fix this component.
I've just started to learn all this. (JS + NR.) And it's much harder to learn the logic of other programmers and try to find & fix what they did wrong or lazy.

That's why I said:

  • it would be better to drop it fully and find a better solution.

Of course I will look into it first, before I start judging, but can not promise anything.
Those errors indicate this node has no proper error handling / reconnecting code inside.

2 Likes
10

Thanks for the confirmation, it's good to know it's not just me being to dumb.

I'd be more careful with such statements, could be a dependency problem or so.
Or at least you'd think one would test a node to some extend before releasing an updated version. Maybe it worked fine with an older node-red version once. But then again I updated node-red a couple times and the newer available version never fully worked. I wonder if I can get the old version working again somehow.

On the long run your probably right. But then it worked so surprisingly well for so long, you know. The identification problem also is a fair point for sure! A more robust solution might definitely be better, I agree.

11

< OFF >

Yes, I know. It's easier to write next to a code: "AS IS" ...and "no responsibility", ... etc
But if someone takes one minute to think about:

  • how many times it already happened, that someone took a code from somewhere and used it, and that caused trouble? :exploding_head:

We are currently building the present / future of automatisation here.
A tiny bit of responsibility would be nice. At least basic safety.

My statement is based on the facts that:

  • Firmata is using plain serial connection, without parity bit and without flow control.
    That is very unsafe already!
  • The fact 2 similar boards can be accidentally swapped >> well, no comment.
    That's really just laziness! It would be easy for a professional to simply add a few lines to force checking the name of the board, and if 2 similar found an error message would prevent to use any of those.
  • Clicking Save As... and giving an other name for all Firmata boards (.ino files) is easy too. :wink:
    Currently it's very hard to find info about it, while it should be on the first line in the code and in the "how to do it" instructions as well.

I feel like those people, whos beloved ones died in an air-plane fire, when they realized:
- "Yes, we knew the seats were flammable..."

Now we still have a good chance to force-implement some basic safety rules to prevent catastrophes, before more people start to use these codes in their homes or even at industrial applications!
:bomb:

14

I had the same execption. After a long deep dive I discovered that I missed to put a Delay Rate Limit on the output. Without it I got the Firmata Exception.

Cheers

1 Like
15

Any solution to this problem? I can't see anything in my log, and have a project due by tomorrow...

16

What did you upgrade ? What do the logs report ?

17

well i just reinstalled the rpiOS and still the same , the arduino on a separate serial is working, but the firmata one is just 'connecting'
what logs could I send?

18

The node-red-log from the console

19 
24 Jan 03:20:31 - [info] Server now running at http://127.0.0.1:1880/
24 Jan 03:20:31 - [info] serial port /dev/ttyACM1 opened at 9600 baud 8N1
24 Jan 03:26:33 - [warn]
---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------
24 Jan 03:26:33 - [info] Stopping flows
24 Jan 03:26:33 - [info] serial port /dev/ttyACM1 closed
24 Jan 03:26:33 - [info] Stopped flows
24 Jan 03:26:33 - [info] Starting flows
24 Jan 03:26:34 - [info] [worldmap:29d1e1b.740569e] started at /worldmap
24 Jan 03:26:34 - [info] Started flows
24 Jan 03:26:34 - [info] serial port /dev/ttyACM1 opened at 9600 baud 8N1
Stopping Node-RED graphical event wiring tool...
24 Jan 06:41:27 - [info] Stopping flows
24 Jan 06:41:27 - [info] serial port /dev/ttyACM1 closed
24 Jan 06:41:27 - [info] Stopped flows
nodered.service: Succeeded.

The serial port: /dev/ttyACM1 is used for basic Arduino
The port i use for firmata is: /dev/ttyACM0

Last night i managed to get it working by reinstalling the npm package manually , and since then it was deployed, now i woke up , and the issue is the same..

UPDATE:
I edited the log level to 'trace' and can't find any further messages regarding of node-red-node-arduino.
I see a message for loading the module:

24 Jan 07:12:42 - [debug] Module: node-red-node-arduino 0.3.1
24 Jan 07:12:42 - [debug]         /home/pi/.node-red/node_modules/node-red-node-arduino
20

So you have two arduinos connected ? Maybe try with just the formata one ? And there is no other application trying to use the port at the same time ?

21

Yes, the setup is remote (so i will have to wait for my friend to wake up to disconnect it)
Last night both of the Arduino's worked great, and when i woke up i saw that the firmata one is reconnecting. I remembered that last night i removed node-red-node-arduino , my friend disconnected the non Firmata Arduino, i reinstalled the node-red-node-arduino, and started N-R, went to the bathroom and when i got back i saw that it was connected...
Maybe i will try that again today (without going to the bathroom :joy:)

Nothing else is trying to use any of the serial ports( new os install)
My Arduino (non Firmata) is sending maybe too much messages will edit that script as well (RPM calculator) maybe that is causing the problems...

22

I don't know about serial ports dev/ttyACMn but I do know that for ports ttyUSBn that the number for a device is not guaranteed. It can change if the port disconnects and reconnects or if the pi reboots. Is it possible that when it works and then fails that it is changing to different ACM number? If it is that then the solution may be to use udev rules to force the device to a device name. Grepping syslog for ACM might give a clue.

2 Likes