Working well for me here.
The one question I would have is about Get Firmware Version. Currently the node returns a string with embedded newlines, as returned by the vcgencmd. I wonder whether it would be more in keeping with node-red if the node were to split this in to an array of strings.
Hello Colin (@Colin),
Thank you (and the others!) for testing!
Yes indeed the newlines looked also a bit weird to me.
Should have mentioned that in my question list above ...
If nobody has an argument against your proposal, I will change it this weekend.
BTW does anybody know where Paul (@Paul-Reed) is at the moment. Hopefully he hasn't vaporized meanwhile, because I'm afraid I still need him for my garage door openers soon 
It is now public domain - happy to share.
I got back from a week's holiday this afternoon!
I've just tried node-red-contrib-vcgencmd and it works just fine here.
It's very easy to use, and also format the outputs. 
Once you've published, I'll make use of it in my dashboards!
Thanks for writing.
Paul
...All except the Control Video Output which works in reverse;
ie. switch video off - and it switches on.
switch video on - and it switches off...
(Was it a test to see if we've checked!!)
It would be good to see a confirmation output for the video output change, currently there's nothing to indicate the status (maybe not possible).
Hope you had a nice time!
And I'm glad you haven't vaporised ...
That would indeed have been a nice test 
But I'm glad that you have tested it. Could you please let me know if it is the power for the Raspberry Touch screen or the hdmi?
My god I have to trust you blindfolded 
But since I cannot test it on my test system currently, I will switch it ...
The vcgencmd command gives me a 0 or 1 as output. So if I translate it (hopefully correctly), you have your confirmation ...
HDMI
I'm not seeing anything from the node payload when the status is changed.
Just had a thought on that.
(And I know that is dangerous)
If the node has all these tick boxes for what the person wants, it will mean that the command will have to be repeated (with different parameters) n times.
Ok. So in light of that and what you said about having multiple nodes doing each different thing:
Having n nodes each doing their own individual thing as opposed to one doing n iterations of the command.
Although it may look nicer having the n nodes, it takes up real estate on the flow edit window.
Granted one node doing multiple things can be confusing.
Which would be less processor loading?
Just that looking at it, you still have to do x amount of work anyway.
Indeed in the current version I throw the return value away. Thought nobody would be interested in it. But you are right that it is good to know where it was a success.
I'm assuming that this wouldn't be a continually running process, so processor loading shouldn't really be a concern either way.
Agreed.
I am just putting it out there.
I am not saying the option of all the tick boxes and the node running that many times over is better.
It is just an option.
Ok guys,
When you install the new version from Github, you will get these updates:
- @Colin: Firmware version payload now contains an array of 3 strings. An example output message is added to the readme page.
- Unless a custom node name has been specified, the selected command option will now automatically be used as node label:
- The node now checks whether the vcgencmd command is supported on the current hardware platform. As explained on the readme page, you will see e.g. in the node status when not supported:
Thanks to our friend Dave (@dceejay) who assisted me to implement this feature! - @Paul-Reed: I have switched 'Display power' On/Off values. Caution: since this is a beta version, I have not added migration code for existing nodes. So 'perhaps' you have to remove your existing nodes and use new ones to see this change ...
- @Paul-Reed: When 'Display power' command is triggered, now an output message will be send containing the feedback from the processor:
Yes I understand your point. But to be honest, I won't use this node myself in the very near future. The development of this node was just my way to say 'thank you' to a group of grumpy old men on this forum (which have helped me already quite some times in the past) So the group can vote whether they want the checkboxes or not. My vote goes to keep it simple (so just 1 single command).
EDIT: Sorry Andrew but I won't be able to add the checkboxes. When you e.g. select 'Video Power' then you will see a dropdown with 'On/Off'. And for other commands you will see other options. So when we would have checkboxes, this mechanism wouldn't work anymore (i.e. you wouldn't see anymore which options correspond to which command). Then it would become too complex. And the grumpy old men didn't help me enough in the past, to get me motivated to rewrite my entire node from scratch
1 Like
Just mentioning.
I tried via the dashboard and couldn't find it. So I tried the CLI method.
That works. Kinda.
(I can't show any of this as it is history)
It said it had installed. But I couldn't find it in the list.
I stopped and started NR. Same.
Did the CLI command again and it said it was uupdating the node. (What!?)
Stopped/Started NR.
Worked.
I would put that down to me and silly things, but!
Having got it working on that RPI, I ssh'ed to another one to install it there. Guess what.
Same.
Got it working after second CLI install, and stop/start NR.
Just saying.
Hi Andrew,
with 'dashboard' I assume you mean the 'flow editor' and not the Node-RED dashboard??
Via 'manage palette' in the menu you won't find this node at the moment, since I haven't published it on NPM yet (so you also won't find it on flows.nodered.org). It is only available on my Github repository, which is why you have to use the CLI command. As soon as the design is good enough for the requesters, I will publish it on NPM for all the users...
1 Like
Thanks. Yes, I did install it via the CLI.
But it still seems I needed to run that command twice before it appeared in the node list (left side of the screen).
That was on two machines. (Maybe 3)
I am a bit overwhelmed with re-writing a lot of flows and re-structuring them.
Yes, I know I should handle this better, but if I try to remember it and tell you later it will be a real mess, as my memory is not good just now.
BTW, it is nice. I have applied it to 3 of my RPIs. (the ones online just now.)
And that has also contributed to a bit of re-writing and new stuff being written.
On a side note: Would you like me to send you my little flow I use for looking at the machine's health? It is code and GUI stuff. Though you may not have all the nodes, you could maybe write around them to get the same result.
Hi folks,
I think/hope we are almost ready to publish it on NPM...
There is a new version on Github, which contains the following changes:
-
Some commands have extra options, like e.g. 'Control video output' can be both 'On' or 'Off'. The selected options are now also displayed in the node label (between brackets):
-
To control the video output, you need two nodes (one for activating and one for deactivating):
In this version you can leave the dropdown empty (i.e. don't select On or Off). In that case you can send on/ON/off/OFF via the msg.payload of the input message:
These example flows are available also on the readme file.
P.S. One of my colleagues at work recently bought an alarm system. As soon as he enters the room, the PIR detector sees him and it sends (via the central system) a trigger to the wall-mount screen in that same room. That way the screen is up-and-running as soon as he wants to use that screen. I had hoped that this node could help me in the future to achieve a similar result: Now I have frequently a 'connection lost' in the dashboard, which solves itself after a few seconds. Would be nice if the connection would be already ok when I arrive at the screen... But Paul says this node only controls the hdmi and not the Rpi touchscreen. So perhaps cannot use this node for that purpose ... Anybody has any ideas about this?
That is unfortunately outside of my knowledge database ... But I will publish it on NPM soon, so then it won't be a problem anymore.
Perhaps you could create a new post on the forum, in the category 'share your projects'. Then everybody can learn from it, and perhaps enrich your solution with extra ideas.
And 1/0 true/false ?
Thought that you guys wanted only human readable values as input and output. But indeed it might offer users the ability to skip a series of Change-nodes in their flows.
So consider it done (i.e. fix is available on Github).
I was thinking input side, just because switches / gpio often default to those anyway.
1 Like
