New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serial port connect/disconnect, configurable reconnect time #1012
Conversation
Hi @htmltiger thank you for taking the time to contribute. It is appreciated. We normally prefer discussion before making a PR so that it aligns with the goals of the project and avoids unnecessary rework or rejection. For example, new features should be based off the dev branch and should therefore target the Dev branch. So the first thing you will need to do is to rebase this PR. Second, #330 was from 2017 - a lot has changed since then. For example, the MQTT nodes now have the runtime control capability (connect/disconnect) and the ability to set the connection properties too. This is done via a |
I have changed connect/disconnect to action to align with mqtt. Thanks for the hint. I will leave it here for anyone who finds it helpful as i have searched in issues/pr for the same features and f for my use and had to modify it so it was necessory for me and possibly for many others who have arduino connected to raspberry pi and want to flash it over ota using avrdude without stopping and starting node-red. Just in case if this pr rejected and anyone stumbling here wants to install this: |
io/serialport/25-serial.html
Outdated
@@ -245,7 +250,8 @@ | |||
bin: {value:"false"}, | |||
out: {value:"char"}, | |||
addchar: {value:""}, | |||
responsetimeout: {value: 10000} | |||
responsetimeout: {value: 10000}, | |||
serialReconnectTime: {value: 15000} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't set this here - as then settings.js would never be able to override... must default to blank
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have updated it, now its an empty string.
Thanks for this - as Steve said we usual prefer some discussion first - as indeed there are two separate things here you are looking at fixing so two PR would have been easier to discuss. So - re the point Steve made - I agree a single action property is cleaner as otherwise you could have specified both msg.connect and msg.disconnect on the same message which could be confusing... Also (I'm on vacation so haven't had a chance to dig into the code yet) - what happens if you send a msg to be sent - once you have disconnected ? hopefully it is handled gracefully ? If you then do disconnect - does the reconnect timer then kick in and try to reconnect ? Is there a flag to stop it retrying ? Then re the 2nd part of the PR - re reconnection. You can't set the default in the node to be 15s - as then the settings.js would not be able to set the default. Any new nodes should be set with a blank (falsey) value so that the settings.js value has priority. |
io/serialport/25-serial.js
Outdated
try { | ||
connections[port].connect(); | ||
} | ||
catch(err) { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to do nothing ? should this raise an error - or set node.status at least ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try catch was not necessory as we are using existing functions to connect so it should be handled in there.
io/serialport/25-serial.js
Outdated
RED.log.info(RED._("serial.errors.closed",{port:port}), {}); | ||
}); | ||
} | ||
catch(err) { } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to do nothing ? should this raise an error - or set node.status at least ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, try catch was not necessory as we are using existing function to disconnect so it should be handled in there.
…cted error log, updates node.status added autoconnect config, checks status before action, prevent unexpected error log, updates node.status
Sure, will keep this in mind for future.
done.
I have checked it and now and there were no errors on serial out node, not sure about request node.
I have added auto connect checkbox (default true as before) and on manual disconnect it stops auto reconnect, on connect it restores old checkbox value.
I have changed it as you have requested but the input field will be blank for now, |
@htmltiger sorry I lost track of this. Do you feel it is ready to go? @dceejay any thoughts moving this forward please? |
@Steve-Mcl yes, it has been running fine since the last changes and its ready to merge. |
Thanks for the feedback. I will review soon (tomorrow / monday) but ultimately, I would want Daves sign off before merging. |
display reconnect time as sec
@dceejay I have tried to import |
Hi @htmltiger great work, but, a few small issues preventing me accepting this PR.
serial-always-connect.mp4
serial-queue-issue.mp4
No 3 This is a Node-RED core thing. A PR will need to be raised against Node-RED Visual stuffA tiny nitpick (a me thing) The layout of the autoconnect check and the reconnect time are a bit too bunched up for my OCD & the row has no icon. Current PRProposedPS: My apologies for not getting this reviewed properly sooner. PS2: If you are not in a position to progress the above please let me know and I will endeavour to take over and get them added to your great work. |
Hi @htmltiger - I totally agree with @Steve-Mcl about the layout - Visual Stuff above and yes re 1 - to me it seems to not honour the flag on deploy - so if you redeploy and it is set to not auto connect - it does so anyway. re 2 - my thinking is that we should drop any messages - as we would also be dropping any incoming ones as we are not connected at that point. Managing queues for messages and retries is a whole different area (and different set of nodes :-) |
@Steve-Mcl feel free to take over or submit changes in this pr. |
Solved this another way by adding a serial control node that can stop, re-configure, and re-start a serial port. See PR #1035 |
Proposed changes
Auto reconnect time changed from hardcoded to configurable.
Add option to disconnect/reconnect serial port on demand.
#330
I have updated locale for english, other langs will need to be updated.
Checklist
grunt
to verify the unit tests pass