Display node: how to set up
-
Reprogramming the weather station it would only be a matter of adding the extra send commands to the display.
I was also thinking that this would be a case where mqtt would come handy, since you can get all the sensor data from pretty much anything that has an ip connection to the mqtt server. -
@gohan I would like to leave the weather station reprogramming as the last option since it was built in the v1.5 period and calibrated. Never try to repair a working device :)
In general I would like to develop a solution where display nodes can be added to the network not having to change other nodes for that. The independency of using display nodes without having to change sensor nodes would be great to achieve.
@mfalkvidd I'll try to find out how to request data from the gateway/controller of a specific node. As long as the Pimatic controller is showing the data there must be a way to get it from there. Search the Pimatic forum for now.
-
@gohan I would like to leave the weather station reprogramming as the last option since it was built in the v1.5 period and calibrated. Never try to repair a working device :)
In general I would like to develop a solution where display nodes can be added to the network not having to change other nodes for that. The independency of using display nodes without having to change sensor nodes would be great to achieve.
@mfalkvidd I'll try to find out how to request data from the gateway/controller of a specific node. As long as the Pimatic controller is showing the data there must be a way to get it from there. Search the Pimatic forum for now.
@Petjepet
If you want more flexibility, I think mqtt is the best solution as you can add as many displays as you want, you could make an esp8266 mqtt gateway with display and nrf24 radio (if needed) or just an esp8266 with display with simple mqtt client (not mysensors) that subscribes to topics in the mqtt server and displays values. -
@gohan I would like to leave the weather station reprogramming as the last option since it was built in the v1.5 period and calibrated. Never try to repair a working device :)
In general I would like to develop a solution where display nodes can be added to the network not having to change other nodes for that. The independency of using display nodes without having to change sensor nodes would be great to achieve.
@mfalkvidd I'll try to find out how to request data from the gateway/controller of a specific node. As long as the Pimatic controller is showing the data there must be a way to get it from there. Search the Pimatic forum for now.
@Petjepet I have not done a lot with the request feature but here is how I understand it works.
A node can make a request to the controller for information about its own child sensors by using request in its sketch. Typically this would be in the loop section of the sketch. The request is issued with the following line.
request( sensorId, messageType)
So if you had a binary switch sensor with a child id of 1 and you wanted to check on its status you would write it like this.
request( 1, V_STATUS);The request is then processed by your controller and the result is returned to the node that sent the request. You then need to have code on that node to do something with this information.
As you have already noted this is where the void receive function is used.
So for our example of a binary switch we could use something as simple as this
void receive(const MyMessage &message) { if (message.type == V_STATUS) { //put code here to be executed when the return from the request arrives } }If you have more than one child sensor that you are expecting returns from you could extend the code using message.sensor to test for which sensor the return is for.
void receive(const MyMessage &message) { if (message.type == V_STATUS) { switch (message.sensor) { case 1: //incoming message is for sensor 1 // put code here to be executed when the message is for sensor 1 break; case 2: //incoming message is for sensor 2 // put code here to be executed when the message is for sensor 2 break; } } }If you wanted to separate returns from a request from normal messages from your controller. You can use message.getCommand()
If you look in the send and receive serial data for your node you will see the command type for a request shown as c=2 , so you just need to test for type 2 commands.void receive(const MyMessage &message) { if (message.type == V_STATUS) { if (message.getCommand() == 2){ // put code here to be executed when the message is from a request } else { //process the message as per normal switch (message.sensor) { case 1: //incoming message is for sensor 1 // put code here to be executed when the message is for sensor 1 break; case 2: //incoming message is for sensor 2 // put code here to be executed when the message is for sensor 2 break; } } } }Making a direct request to another node is also possible. To do that you can use the optional third parameter in the request statement which is for the node id that you are requesting information from.
The default is set to 0 which is the gateway but you can use the node id to select another destination.
So if we wanted information from a binary switch sensor with an id of 1 which is on a node with an id of 20 we would do this
request( 1, V_STATUS, 20);The gateway will rout this request to the desired node but it will be up to you to have code on that node to both read the request and then send a reply back to the node that asked for the information. Of course you will also need code on the sending node to process the request when it is returned
-
@Petjepet I have not done a lot with the request feature but here is how I understand it works.
A node can make a request to the controller for information about its own child sensors by using request in its sketch. Typically this would be in the loop section of the sketch. The request is issued with the following line.
request( sensorId, messageType)
So if you had a binary switch sensor with a child id of 1 and you wanted to check on its status you would write it like this.
request( 1, V_STATUS);The request is then processed by your controller and the result is returned to the node that sent the request. You then need to have code on that node to do something with this information.
As you have already noted this is where the void receive function is used.
So for our example of a binary switch we could use something as simple as this
void receive(const MyMessage &message) { if (message.type == V_STATUS) { //put code here to be executed when the return from the request arrives } }If you have more than one child sensor that you are expecting returns from you could extend the code using message.sensor to test for which sensor the return is for.
void receive(const MyMessage &message) { if (message.type == V_STATUS) { switch (message.sensor) { case 1: //incoming message is for sensor 1 // put code here to be executed when the message is for sensor 1 break; case 2: //incoming message is for sensor 2 // put code here to be executed when the message is for sensor 2 break; } } }If you wanted to separate returns from a request from normal messages from your controller. You can use message.getCommand()
If you look in the send and receive serial data for your node you will see the command type for a request shown as c=2 , so you just need to test for type 2 commands.void receive(const MyMessage &message) { if (message.type == V_STATUS) { if (message.getCommand() == 2){ // put code here to be executed when the message is from a request } else { //process the message as per normal switch (message.sensor) { case 1: //incoming message is for sensor 1 // put code here to be executed when the message is for sensor 1 break; case 2: //incoming message is for sensor 2 // put code here to be executed when the message is for sensor 2 break; } } } }Making a direct request to another node is also possible. To do that you can use the optional third parameter in the request statement which is for the node id that you are requesting information from.
The default is set to 0 which is the gateway but you can use the node id to select another destination.
So if we wanted information from a binary switch sensor with an id of 1 which is on a node with an id of 20 we would do this
request( 1, V_STATUS, 20);The gateway will rout this request to the desired node but it will be up to you to have code on that node to both read the request and then send a reply back to the node that asked for the information. Of course you will also need code on the sending node to process the request when it is returned
@Boots33 Thanks for the explanation!
However, as mentioned in an earlier post, I can't directly request data from the weather station node since it is battery operated and uses a sleep to save power. In this case the node will not react to a request.I'm now using the receive command exactly in the way you mentioned by determining the sensor in the message to get the correct data for the right value to display in my Display node.
In Pimatic I set up a rule to send the data of the latest received value of the weatherstation node, triggered by a change of that value (when weather station node is sending a new value). The point is now that this is a push functionality by Pimatic where I'm looking for a pull mechanisme to be done by the Display node to Pimatic. -
@Boots33 Thanks for the explanation!
However, as mentioned in an earlier post, I can't directly request data from the weather station node since it is battery operated and uses a sleep to save power. In this case the node will not react to a request.I'm now using the receive command exactly in the way you mentioned by determining the sensor in the message to get the correct data for the right value to display in my Display node.
In Pimatic I set up a rule to send the data of the latest received value of the weatherstation node, triggered by a change of that value (when weather station node is sending a new value). The point is now that this is a push functionality by Pimatic where I'm looking for a pull mechanisme to be done by the Display node to Pimatic.@Petjepet I don't have experience with pimatic but would assume you can use a similar mechanism I use in Domoticz and MyController.
- Have you display node define "sensors" for the variables to display. These will be available (and "requestable") in your controller.
- Do some programming (rule or other magic) in your controller to copy the Weatherstation reported values to the display "sensors".
- Let the display node request()/"pull" the value from the controller.
As my display nodes are pretty dumb displays I let the controller built "V_TEXT" containing the formatted display information. An ancient example.
-
@Petjepet I don't have experience with pimatic but would assume you can use a similar mechanism I use in Domoticz and MyController.
- Have you display node define "sensors" for the variables to display. These will be available (and "requestable") in your controller.
- Do some programming (rule or other magic) in your controller to copy the Weatherstation reported values to the display "sensors".
- Let the display node request()/"pull" the value from the controller.
As my display nodes are pretty dumb displays I let the controller built "V_TEXT" containing the formatted display information. An ancient example.
-
-
@Boots33 Display nodes are convenient in monitoring status of other nodes. I would like to have a Display node in the lead for this (on request).
In this way new Display nodes can be set up more easily without having to update the controller for each change on Display nodes.
If Pimatic would be able to handle the 'request()' for the node doing the request it would be great I think (like your solution). -
@Boots33 Display nodes are convenient in monitoring status of other nodes. I would like to have a Display node in the lead for this (on request).
In this way new Display nodes can be set up more easily without having to update the controller for each change on Display nodes.
If Pimatic would be able to handle the 'request()' for the node doing the request it would be great I think (like your solution).@Petjepet I am not familiar with Pimatic but could a workaround be that you add a binary switch sensor to your display node and then have it trigger the switch when it requires data from the controller.
Then on the controller have it send the data when it sees a change on that switch.
-
@Petjepet I am not familiar with Pimatic but could a workaround be that you add a binary switch sensor to your display node and then have it trigger the switch when it requires data from the controller.
Then on the controller have it send the data when it sees a change on that switch.
-
@gohan Sorry I didn't answer that this weekend.
I tried many times before to build a ESP8266 Gateway and ended up in frustrating continuous reboot issues.
So I gave up on that.
I have now a Serial Gateway working fine.How would a MQTT gateway benefit more in the issue I have not being able to directly retrieve data from the controller?
-
There are some videos on youtube explaining what MQTT is, but basically if you have your Mysensors gateway publishing to an mqtt server/broker you can have multiple clients subscribing to the same topic (or different ones too, depending on the needs) so that as soon as the node sends the data to gateway, gateway publishes that data on the mqtt server, mqtt server sends data to all mqtt clients that have subscribed to the topic where the data have changed. This way you have push updates on the display nodes and you can configure mqtt to retain last published data from the sensors.
Of course you would have to configure you controller to use the mqtt server instead of serial. I am running Domoticz connected to mqtt with mysensors and it is working fine. Using MQTT it allows also to quickly connect other programs like node-red or whatever controller/dashboards without too much effort
-
There are some videos on youtube explaining what MQTT is, but basically if you have your Mysensors gateway publishing to an mqtt server/broker you can have multiple clients subscribing to the same topic (or different ones too, depending on the needs) so that as soon as the node sends the data to gateway, gateway publishes that data on the mqtt server, mqtt server sends data to all mqtt clients that have subscribed to the topic where the data have changed. This way you have push updates on the display nodes and you can configure mqtt to retain last published data from the sensors.
Of course you would have to configure you controller to use the mqtt server instead of serial. I am running Domoticz connected to mqtt with mysensors and it is working fine. Using MQTT it allows also to quickly connect other programs like node-red or whatever controller/dashboards without too much effort
-
@Petjepet I have not done a lot with the request feature but here is how I understand it works.
A node can make a request to the controller for information about its own child sensors by using request in its sketch. Typically this would be in the loop section of the sketch. The request is issued with the following line.
request( sensorId, messageType)
So if you had a binary switch sensor with a child id of 1 and you wanted to check on its status you would write it like this.
request( 1, V_STATUS);The request is then processed by your controller and the result is returned to the node that sent the request. You then need to have code on that node to do something with this information.
As you have already noted this is where the void receive function is used.
So for our example of a binary switch we could use something as simple as this
void receive(const MyMessage &message) { if (message.type == V_STATUS) { //put code here to be executed when the return from the request arrives } }If you have more than one child sensor that you are expecting returns from you could extend the code using message.sensor to test for which sensor the return is for.
void receive(const MyMessage &message) { if (message.type == V_STATUS) { switch (message.sensor) { case 1: //incoming message is for sensor 1 // put code here to be executed when the message is for sensor 1 break; case 2: //incoming message is for sensor 2 // put code here to be executed when the message is for sensor 2 break; } } }If you wanted to separate returns from a request from normal messages from your controller. You can use message.getCommand()
If you look in the send and receive serial data for your node you will see the command type for a request shown as c=2 , so you just need to test for type 2 commands.void receive(const MyMessage &message) { if (message.type == V_STATUS) { if (message.getCommand() == 2){ // put code here to be executed when the message is from a request } else { //process the message as per normal switch (message.sensor) { case 1: //incoming message is for sensor 1 // put code here to be executed when the message is for sensor 1 break; case 2: //incoming message is for sensor 2 // put code here to be executed when the message is for sensor 2 break; } } } }Making a direct request to another node is also possible. To do that you can use the optional third parameter in the request statement which is for the node id that you are requesting information from.
The default is set to 0 which is the gateway but you can use the node id to select another destination.
So if we wanted information from a binary switch sensor with an id of 1 which is on a node with an id of 20 we would do this
request( 1, V_STATUS, 20);The gateway will rout this request to the desired node but it will be up to you to have code on that node to both read the request and then send a reply back to the node that asked for the information. Of course you will also need code on the sending node to process the request when it is returned
@Boots33 I was wondering if the request function could be used to set the sleep time from the controller, like when the nodes wakes up it requests the value of the "sleep" sensor and then goes back to sleep with that new value in case it has been updated (is would kind of a bad copy of the smartsleep)
-
@Boots33 I was wondering if the request function could be used to set the sleep time from the controller, like when the nodes wakes up it requests the value of the "sleep" sensor and then goes back to sleep with that new value in case it has been updated (is would kind of a bad copy of the smartsleep)
