2015-06-13 19:45:38 +02:00
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-template-name = "serial in" >
2015-06-13 19:45:38 +02:00
< div class = "form-row node-input-serial" >
2015-06-16 11:36:19 +02:00
< label for = "node-input-serial" > < i class = "fa fa-random" > < / i > < span data-i18n = "serial.label.serialport" > < / span > < / label >
2015-06-13 19:45:38 +02:00
< input type = "text" id = "node-input-serial" >
< / div >
< div class = "form-row" >
2015-06-16 12:16:29 +02:00
< label for = "node-input-name" > < i class = "fa fa-tag" > < / i > < span data-i18n = "node-red:common.label.name" > < / span > < / label >
< input type = "text" id = "node-input-name" data-i18n = "[placeholder]node-red:common.label.name" >
2015-06-13 19:45:38 +02:00
< / div >
< / script >
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-help-name = "serial in" >
2015-06-13 19:45:38 +02:00
< p > Reads data from a local serial port.< / p >
2017-11-04 18:12:48 +01:00
< p > Can either < ul > < li > wait for a "split" character (default \n). Also accepts hex notation (0x0d).< / li >
2018-02-19 20:21:52 +01:00
< li > Wait for a timeout in milliseconds from the first character received< / li >
2015-06-16 11:36:19 +02:00
< li > Wait to fill a fixed sized buffer< / li > < / ul > < / p >
2016-02-12 14:14:12 +01:00
< p > It then outputs < code > msg.payload< / code > as either a UTF8 ascii string or a binary Buffer object.< / p >
2018-03-01 19:21:22 +01:00
< p > < code > msg.port< / code > is set to the name of the port selected.< / p >
2016-04-01 09:55:50 +02:00
< p > If no split character is specified, or a timeout or buffer size of 0, then a stream of single characters
is sent - again either as ascii chars or size 1 binary buffers.< / p >
2015-06-13 19:45:38 +02:00
< / script >
< script type = "text/javascript" >
RED.nodes.registerType('serial in',{
2019-09-30 10:46:48 +02:00
category: 'network',
2015-06-13 19:45:38 +02:00
defaults: {
name: {name:""},
serial: {type:"serial-port",required:true}
},
color:"BurlyWood",
inputs:0,
outputs:1,
icon: "serial.png",
label: function() {
var serialNode = RED.nodes.node(this.serial);
2015-06-16 11:36:19 +02:00
return this.name||(serialNode?serialNode.label().split(":")[0]:this._("serial.label.serial"));
2015-06-13 19:45:38 +02:00
},
labelStyle: function() {
return this.name?"node_label_italic":"";
2019-09-30 10:46:48 +02:00
},
outputLabels: function() { return RED.nodes.node(this.serial).bin === "bin" ? "buffer" : "string"; }
2015-06-13 19:45:38 +02:00
});
< / script >
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-template-name = "serial out" >
2015-06-13 19:45:38 +02:00
< div class = "form-row node-input-serial" >
2015-06-16 11:36:19 +02:00
< label for = "node-input-serial" > < i class = "fa fa-random" > < / i > < span data-i18n = "serial.label.serialport" > < / span > < / label >
2015-06-13 19:45:38 +02:00
< input type = "text" id = "node-input-serial" >
< / div >
< div class = "form-row" >
2015-06-16 12:16:29 +02:00
< label for = "node-input-name" > < i class = "fa fa-tag" > < / i > < span data-i18n = "node-red:common.label.name" > < / span > < / label >
< input type = "text" id = "node-input-name" data-i18n = "[placeholder]node-red:common.label.name" >
2015-06-13 19:45:38 +02:00
< / div >
< / script >
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-help-name = "serial out" >
2015-06-13 19:45:38 +02:00
< p > Provides a connection to an outbound serial port.< / p >
2016-02-12 14:14:12 +01:00
< p > Only the < code > msg.payload< / code > is sent.< / p >
2015-06-13 19:45:38 +02:00
< p > Optionally the new line character used to split the input can be appended to every message sent out to the serial port.< / p >
2016-02-12 14:14:12 +01:00
< p > Binary payloads can be sent by using a Buffer object.< / p >
2015-06-13 19:45:38 +02:00
< / script >
< script type = "text/javascript" >
RED.nodes.registerType('serial out',{
2019-09-30 10:46:48 +02:00
category: 'network',
2015-06-13 19:45:38 +02:00
defaults: {
name: {name:""},
serial: {type:"serial-port",required:true}
},
color:"BurlyWood",
inputs:1,
outputs:0,
icon: "serial.png",
align: "right",
label: function() {
var serialNode = RED.nodes.node(this.serial);
2015-06-16 11:36:19 +02:00
return this.name||(serialNode?serialNode.label().split(":")[0]:this._("serial.label.serial"));
2015-06-13 19:45:38 +02:00
},
labelStyle: function() {
return this.name?"node_label_italic":"";
}
});
< / script >
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-template-name = "serial request" >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< div class = "form-row node-input-serial" >
< label for = "node-input-serial" > < i class = "fa fa-random" > < / i > < span data-i18n = "serial.label.serialport" > < / span > < / label >
< input type = "text" id = "node-input-serial" >
< / div >
< div class = "form-row" >
< label for = "node-inputoutput-name" > < i class = "fa fa-tag" > < / i > < span data-i18n = "node-red:common.label.name" > < / span > < / label >
< input type = "text" id = "node-input-name" data-i18n = "[placeholder]node-red:common.label.name" >
< / div >
< / script >
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-help-name = "serial request" >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< p > Provides a connection to a request/response serial port.< / p >
< p > This node behaves as a tightly coupled combination of < code > serial in< / code > and < code > serial out< / code > nodes,
with which it shares the configuration.< / p >
< p > Send the request message in < code > msg.payload< / code > as you would do with a < code > serial out< / code > node.
The message will be forwarded to the serial port following a strict FIFO (First In, First Out) queue, waiting for a single response before transmitting the next request.
2019-04-04 23:20:21 +02:00
Once a response is received (with the same logic of a < code > serial in< / code > node), or after a timeout occurs, a message is sent to the output (see Outputs below),
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
with < code > msg.payload< / code > containing the received response (or missing in case if timeout) and all other fields preserved.< / p >
< p > For consistency with the < code > serial in< / code > node, < code > msg.port< / code > is set to the name of the port selected.< / p >
< h3 > Inputs< / h3 >
< ul >
< li >
< code > msg.timeout< / code > is the timeout (in ms) after which the incoming message is propagated to the output with < code > msg.status< / code > set to < code > "ERR_TIMEOUT"< / code > and missing payload.
If not present, the default value is 10000 (10s).
< / li >
2019-04-04 23:20:21 +02:00
< li > < code > msg.count< / code > if set this will override the configured number of characters as long as it is less than the number configured.< / li >
< li > < code > msg.waitfor< / code > single character, escape code, or hex code. If set, the node will wait until it matches that character in the stream and then start the output.< / li >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< / ul >
< h3 > Outputs< / h3 >
< ul >
< li > < code > msg.payload< / code > is the response. If no response occured, this field is removed.< / li >
< li > < code > msg.status< / code > is < code > "OK"< / code > in case a response is received, or < code > "ERR_TIMEOUT"< / code > if a timeout occurs.< / li >
< li > Any other field coming from the input will be preserved.< / li >
< / ul >
< / script >
< script type = "text/javascript" >
RED.nodes.registerType('serial request',{
2019-09-30 10:46:48 +02:00
category: 'network',
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
defaults: {
name: {name:""},
serial: {type:"serial-port",required:true}
},
color:"BurlyWood",
inputs:1,
outputs:1,
icon: "serial.png",
align: "left",
label: function() {
var serialNode = RED.nodes.node(this.serial);
return this.name||(serialNode?serialNode.label().split(":")[0]:this._("serial.label.serial"));
},
labelStyle: function() {
return this.name?"node_label_italic":"";
2019-09-30 10:46:48 +02:00
},
outputLabels: function() { return RED.nodes.node(this.serial).bin === "bin" ? "buffer" : "string"; }
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
});
< / script >
2015-06-13 19:45:38 +02:00
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-template-name = "serial-port" >
2015-06-13 19:45:38 +02:00
< div class = "form-row" >
2015-06-16 11:36:19 +02:00
< label for = "node-config-input-serialport" > < i class = "fa fa-random" > < / i > < span data-i18n = "serial.label.serialport" > < / span > < / label >
2018-06-02 14:24:57 +02:00
< input type = "text" id = "node-config-input-serialport" style = "width:66%;" data-i18n = "[placeholder]serial.placeholder.serialport" >
2019-11-13 19:43:43 +01:00
< a id = "node-config-lookup-serial" class = "red-ui-button" > < i id = "node-config-lookup-serial-icon" class = "fa fa-search" > < / i > < / a >
2015-06-13 19:45:38 +02:00
< / div >
< div class = "form-row" >
2016-04-01 09:55:50 +02:00
< table width = "100%" > < tr >
< td width = "100px" > < i class = "fa fa-wrench" > < / i > < span data-i18n = "serial.label.settings" > < / span > < / td >
< td width = "110px" data-i18n = "serial.label.baudrate" > < / td >
< td width = "70px" data-i18n = "serial.label.databits" > < / td >
2015-06-16 11:36:19 +02:00
< td width = "80px" data-i18n = "serial.label.parity" > < / td >
2016-04-01 09:55:50 +02:00
< td width = "70px" data-i18n = "serial.label.stopbits" > < / td >
2015-06-13 19:45:38 +02:00
< / tr > < tr > < td > < / td >
< td >
2018-06-02 14:24:57 +02:00
< input type = "text" id = "node-config-input-serialbaud" style = "width:92%" >
2015-06-13 19:45:38 +02:00
< / td > < td >
2018-06-02 14:24:57 +02:00
< select type = "text" id = "node-config-input-databits" style = "width:90%;" >
2015-06-13 19:45:38 +02:00
< option value = "8" > 8< / option >
< option value = "7" > 7< / option >
< option value = "6" > 6< / option >
< option value = "5" > 5< / option >
< / select >
< / td > < td >
2018-06-02 14:24:57 +02:00
< select type = "text" id = "node-config-input-parity" style = "width:90%;" >
2015-06-16 11:36:19 +02:00
< option value = "none" data-i18n = "serial.parity.none" > < / option >
< option value = "even" data-i18n = "serial.parity.even" > < / option >
< option value = "mark" data-i18n = "serial.parity.mark" > < / option >
< option value = "odd" data-i18n = "serial.parity.odd" > < / option >
< option value = "space" data-i18n = "serial.parity.space" > < / option >
2015-06-13 19:45:38 +02:00
< / select >
< / td > < td >
2018-06-02 14:24:57 +02:00
< select type = "text" id = "node-config-input-stopbits" style = "width:90%;" >
2015-06-13 19:45:38 +02:00
< option value = "2" > 2< / option >
< option value = "1" > 1< / option >
< / select >
2018-06-02 14:24:57 +02:00
< / td > < / tr > < / table >
< / div >
2019-04-04 23:20:21 +02:00
< div class = "form-row" style = "margin-top:16px; margin-bottom:0;" >
2015-06-16 11:36:19 +02:00
< label > < i class = "fa fa-sign-in" > < / i > < span data-i18n = "serial.label.input" > < / span > < / label >
2015-06-13 19:45:38 +02:00
< / div >
2019-04-04 23:20:21 +02:00
< div class = "form-row" style = "padding-left:18px; margin-bottom:4px;" >
< span data-i18n = "serial.label.start" > < / span >
< input type = "text" id = "node-config-input-waitfor" style = "width:50px; height:28px;" >
< span data-i18n = "serial.label.startor" > < / span >
< / div >
< div class = "form-row" style = "padding-left:18px; margin-bottom:4px;" >
2015-06-16 11:36:19 +02:00
< span data-i18n = "serial.label.split" > < / span >
2019-04-04 23:20:21 +02:00
< select type = "text" id = "node-config-input-out" style = "margin-left:11px; width:200px; height:28px;" >
2015-06-16 11:36:19 +02:00
< option value = "char" data-i18n = "serial.split.character" > < / option >
< option value = "time" data-i18n = "serial.split.timeout" > < / option >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< option value = "interbyte" data-i18n = "serial.split.silent" > < / option >
2015-06-16 11:36:19 +02:00
< option value = "count" data-i18n = "serial.split.lengths" > < / option >
2015-06-13 19:45:38 +02:00
< / select >
2019-04-04 23:20:21 +02:00
< input type = "text" id = "node-config-input-newline" style = "width:50px; height:28px;" >
2015-06-13 19:45:38 +02:00
< span id = "node-units" > < / span >
< / div >
2019-04-04 23:20:21 +02:00
< div class = "form-row" style = "padding-left:18px; margin-bottom:4px;" >
2015-06-16 11:36:19 +02:00
< span data-i18n = "serial.label.deliver" > < / span >
2019-04-04 23:20:21 +02:00
< select type = "text" id = "node-config-input-bin" style = "margin-left:5px; width:150px; height:28px;" >
2015-06-16 11:36:19 +02:00
< option value = "false" data-i18n = "serial.output.ascii" > < / option >
< option value = "bin" data-i18n = "serial.output.binary" > < / option >
2015-06-13 19:45:38 +02:00
< / select >
< / div >
< div id = "node-config-addchar" >
2019-04-04 23:20:21 +02:00
< div class = "form-row" style = "margin-top:16px; margin-bottom:0;" >
2015-06-16 11:36:19 +02:00
< label > < i class = "fa fa-sign-out" > < / i > < span data-i18n = "serial.label.output" > < / span > < / label >
2015-06-13 19:45:38 +02:00
< / div >
2019-04-04 23:20:21 +02:00
< div class = "form-row" style = "padding-left:18px; margin-bottom:4px;" >
< label style = "width:auto;" for = "node-config-input-addchar" > < span data-i18n = "serial.addsplit" > < / span > < / label >
< input type = "text" id = "node-config-input-addchar" style = "width:50px; height:28px;" >
2015-06-13 19:45:38 +02:00
< / div >
< / div >
2019-04-04 23:20:21 +02:00
< div id = "node-config-req" >
< div class = "form-row" style = "margin-top:16px; margin-bottom:0;" >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< label > < i class = "fa fa-exchange" > < / i > < span data-i18n = "serial.label.request" > < / span > < / label >
< / div >
2019-04-04 23:20:21 +02:00
< div class = "form-row" style = "padding-left:18px; margin-bottom:18px;" >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< span data-i18n = "serial.label.responsetimeout" > < / span >
2019-04-04 23:20:21 +02:00
< input type = "text" id = "node-config-input-responsetimeout" style = "width:60px; height:28px;" >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< span data-i18n = "serial.label.ms" > < / span >
< / div >
< / div >
2019-04-04 23:20:21 +02:00
< div class = "form-tips" id = "tip-waitfor" hidden > < span data-i18n = "serial.tip.waitfor" > < / span > < / div >
< div class = "form-tips" id = "tip-addchar" hidden > < span data-i18n = "serial.tip.addchar" > < / span > < / div >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< div class = "form-tips" id = "tip-responsetimeout" hidden > < span data-i18n = "serial.tip.responsetimeout" > < / span > < / div >
2015-06-16 11:36:19 +02:00
< div class = "form-tips" id = "tip-split" > < span data-i18n = "serial.tip.split" > < / span > < / div >
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
< div class = "form-tips" id = "tip-timeout" hidden > < span data-i18n = "serial.tip.timeout" > < / span > < / div >
< div class = "form-tips" id = "tip-silent" hidden > < span data-i18n = "serial.tip.silent" > < / span > < / div >
2019-04-04 23:20:21 +02:00
< div class = "form-tips" id = "tip-count" hidden > < span data-i18n = "serial.tip.count" > < / span > < / div >
2015-06-13 19:45:38 +02:00
< / script >
2019-12-01 18:55:08 +01:00
< script type = "text/html" data-help-name = "serial-port" >
2017-11-04 18:12:48 +01:00
< p > Provides configuration options for a serial port.< / p >
< p > The search button should return a list of available serial ports to choose from, or you
can type in the location if known.< / p >
2019-04-04 23:20:21 +02:00
< p > The node can optionally wait until it matches a pre-defined character.
The data can then be split on a fixed character, after a timeout, or after a fixed number of characters.< / p >
2017-11-04 18:12:48 +01:00
< p > If using a character, it can be specified as either the character, the escaped shortcut (e.g. \n), or the hex code (e.g. 0x0d).< / p >
< / script >
2015-06-13 19:45:38 +02:00
< script type = "text/javascript" >
RED.nodes.registerType('serial-port',{
category: 'config',
defaults: {
//name: {value:""},
serialport: {value:"",required:true},
2016-04-01 09:55:50 +02:00
serialbaud: {value:"57600",required:true,validate:RED.validators.number()},
2015-06-13 19:45:38 +02:00
databits: {value:8,required:true},
parity: {value:"none",required:true},
stopbits: {value:1,required:true},
2019-04-04 23:20:21 +02:00
waitfor: {value:""},
2015-06-13 19:45:38 +02:00
newline: {value:"\\n"},
bin: {value:"false"},
out: {value:"char"},
2019-12-01 18:55:08 +01:00
addchar: {value:""},
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
responsetimeout: {value: 10000}
2015-06-13 19:45:38 +02:00
},
label: function() {
this.serialbaud = this.serialbaud || 57600;
this.databits = this.databits || 8;
2015-06-16 11:36:19 +02:00
this.parity = this.parity || this._("serial.label.none");
2015-06-13 19:45:38 +02:00
this.stopbits = this.stopbits || 1;
return this.serialport+":"+this.serialbaud+"-"+this.databits+this.parity.charAt(0).toUpperCase()+this.stopbits;
},
oneditprepare: function() {
var previous = null;
2016-04-01 09:55:50 +02:00
var blist = [
{value:"115200",label:"115200",hasValue:false},
{value:"57600",label:"57600",hasValue:false},
{value:"38400",label:"38400",hasValue:false},
{value:"19200",label:"19200",hasValue:false},
{value:"9600",label:"9600",hasValue:false},
{value:"4800",label:"4800",hasValue:false},
{value:"2400",label:"2400",hasValue:false},
{value:"1200",label:"1200",hasValue:false},
{value:"600",label:"600",hasValue:false},
{value:"300",label:"300",hasValue:false},
{label:"other",value:"other",icon:"red/images/typedInput/09.png",validate:/^[0-9]*$/}
];
var serialbaudType = "custom";
for (var i in blist) {
if (this.serialbaud == blist[i].value) {
serialbaudType = this.serialbaud;
}
}
$("#node-config-input-serialbaud").typedInput({
default: this.serialbaud,
types:blist
});
2015-06-13 19:45:38 +02:00
$("#node-config-input-out").on('focus', function () { previous = this.value; }).change(function() {
if (previous == null) { previous = $("#node-config-input-out").val(); }
if ($("#node-config-input-out").val() == "char") {
if (previous != "char") { $("#node-config-input-newline").val("\\n"); }
$("#node-units").text("");
2019-04-04 23:20:21 +02:00
// $("#node-config-addchar").show();
2015-06-13 19:45:38 +02:00
$("#tip-split").show();
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
$("#tip-timeout").hide();
$("#tip-silent").hide();
2019-04-04 23:20:21 +02:00
$("#tip-count").hide();
2015-06-13 19:45:38 +02:00
}
else if ($("#node-config-input-out").val() == "time") {
if (previous != "time") { $("#node-config-input-newline").val("0"); }
$("#node-units").text("ms");
2019-04-04 23:20:21 +02:00
// $("#node-config-addchar").hide();
// $("#node-config-input-addchar").val("false");
2015-06-13 19:45:38 +02:00
$("#tip-split").hide();
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
$("#tip-timeout").show();
$("#tip-silent").hide();
2019-04-04 23:20:21 +02:00
$("#tip-count").hide();
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
}
else if ($("#node-config-input-out").val() == "interbyte") {
if (previous != "interbyte") { $("#node-config-input-newline").val("0"); }
$("#node-units").text("ms");
2019-04-04 23:20:21 +02:00
// $("#node-config-addchar").hide();
// $("#node-config-input-addchar").val("false");
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
$("#tip-split").hide();
$("#tip-timeout").hide();
$("#tip-silent").show();
2019-04-04 23:20:21 +02:00
$("#tip-count").hide();
2015-06-13 19:45:38 +02:00
}
else {
if (previous != "count") { $("#node-config-input-newline").val(""); }
$("#node-units").text("chars");
2019-04-04 23:20:21 +02:00
// $("#node-config-addchar").hide();
// $("#node-config-input-addchar").val("false");
2015-06-13 19:45:38 +02:00
$("#tip-split").hide();
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
$("#tip-timeout").hide();
$("#tip-silent").hide();
2019-04-04 23:20:21 +02:00
$("#tip-count").show();
2015-06-13 19:45:38 +02:00
}
});
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
$("#node-config-input-responsetimeout").on('focus', function () { $("#tip-responsetimeout").show(); });
2019-04-04 23:20:21 +02:00
$("#node-config-input-responsetimeout").on('blur', function () { $("#tip-responsetimeout").hide(); });
$("#node-config-input-waitfor").on('focus', function () { $("#tip-waitfor").show(); });
$("#node-config-input-waitfor").on('blur', function () { $("#tip-waitfor").hide(); });
$("#node-config-input-addchar").on('focus', function () { $("#tip-addchar").show(); });
$("#node-config-input-addchar").on('blur', function () { $("#tip-addchar").hide(); });
Serial request (#426)
* serial: simplify serialPool.get
serialPool.get() has a lot of arguments.
Just pass the whole serialConfig object instead.
Also introduce early termination to remove one level of indentation.
(Just set your diff tool to ignore all whitespace changes to see
how very little this patch changes)
* serial: move splitting logic onto serialPool
All SerialIn and SerialOut nodes for a given port
share the same splitting logic as it is indeed
set by the common configuration node.
Move the code from SerialIn into serialPool so that
it can be reused by the serial request node.
Notice how the 'data' event will no longer carry
single bytes, but the whole payload instead.
Also move the output encoding logic into serialPool.
* serial: add serial request node
Add a "serial request" node to handle simple request/response
protocols. This node allows for multiple instances, all
sharing the same underlying device.
Responses coming from the serial line will only be propagated
to the output of the node where the request was originally received
(contrary to the "serial in" nodes which all emit the data
received from the serial line).
Every request received as an input to the node, is transmitted
to the serial line, and a matching response must be received
before the next one can be transmitted.
Any input message received in the meantime is internally enqueued.
The node is essentially a merge of serial in and serial out.
It shares the same configuration with serial in and serial out
for any given port and will not affect the behavior of the
existing nodes.
This means you can use, alongside with the request node:
- as many serial in nodes as you want -- e.g. to "sniff"
- serial out to inject mailicious/tampering data onto the serial
line, skipping the queueing mechanism
* serial request: provide some visual feedback on the node
add status indication:
- yellow "waiting" when a message is enqueued for sending
- green "OK" after an answer is received
- red "timeout" after a timeout occurs
More sofisticated output would include an indication of the number of messages
enqueued and the actual timeout remaining after sending.
* serial request: make default response timeout configurable
Notice it's a global setting (i.e. stored in the configuration node)
as opposed to per-node, but it can be overridden by setting msg.timeout.
* serial request: cosmetic changes
- added documentation about msg.port
- timeout field made wider so to accommodate default value of 10000ms
- replaced harcoded text with localizable strings for
"waiting" and "timeout" messages
* serial: cleanup: remove node.tout
this was probably some leftover code from previous implementations.
Now all timeouts are handled within the connection objects.
* serial: cleanup: set obj.tout to null after clearing it
clearing a Timeout without setting it back to null *might* have
adverse effects on later code which would check its null-ity.
Let's just do it.
* serial: cosmetic: add some comments
* serial request: fix "split on timeout" case
In the case of "split on timeout" case, we're reusing the same
.tout for two different purposes:
1) to send a timeout message, in case no answer is received at all [request]
2) to split messages, after receiving the first character [in+request]
So in the case of serial request, checking whether .tout is already
set is no longer a valid condition for 2).
Let's just check whether i === 1, and clear the timeout set up by 1)
if it's already there.
* serial: add "split on silence" behavior
add a fourth logic to split incoming data into messages.
The existing "split on timeout" logic starts the timeout upon
reception of the first character.
This might lead to unwanted behavior if for instance Node-RED is
restarted, as data might accumulate into OS buffers (see #410).
A different logic might be to only emit a message when enough time
has passed, without any new data being received (line silent), a.k.a.
interbyte timeout.
2018-07-09 12:14:08 +02:00
2015-06-13 19:45:38 +02:00
try {
$("#node-config-input-serialport").autocomplete( "destroy" );
} catch(err) {
}
$("#node-config-lookup-serial").click(function() {
$("#node-config-lookup-serial").addClass('disabled');
$.getJSON('serialports',function(data) {
$("#node-config-lookup-serial").removeClass('disabled');
2019-11-13 19:43:43 +01:00
var ports = data || [];
2015-06-13 19:45:38 +02:00
$("#node-config-input-serialport").autocomplete({
source:ports,
minLength:0,
close: function( event, ui ) {
$("#node-config-input-serialport").autocomplete( "destroy" );
}
}).autocomplete("search","");
});
});
2016-04-01 09:55:50 +02:00
},
oneditsave: function() {
var mytype = $("#node-config-input-serialbaud").typedInput('type');
if (mytype !== "other") {
$("#node-config-input-serialbaud").typedInput('value',mytype);
}
this.serialbaud = $("#node-config-input-serialbaud").typedInput('value');
2015-06-13 19:45:38 +02:00
}
});
< / script >
