which sensor and msg type for switch/dimmer node (sender only)?
-
hello everyone,
I'm currently working on a customized livolo touch switch (see https://forum.mysensors.org/topic/7836/what-did-you-build-today-pictures/162, https://forum.mysensors.org/topic/7836/what-did-you-build-today-pictures/163, https://forum.mysensors.org/topic/7836/what-did-you-build-today-pictures/292), which act as a "wireless remote" only. no direct power/lamp switching/dimming will be managed by this node, but the controlling only.
based on the instructions it provide (on/off/dimm level) the corresponding pair node has to do the necessary control.
the touch surface has two color LED feedback, so it should also receive messages from the controller to update its status when the light is switched from another location or from software.I'm basically ready with the electronics, it is assembled, tested, everything works as expected.
so, my question is, which sensor node type and messages would be ideal for this node?it would be also important to be able to communicate directly with the actuators without involving the controller, just to be sure, that lamps could be switched even in case of a "service outage". I'm also looking for the relevant technical details for this.
JFYI, final details (including hw/sw design) will be shared on openhardware.io as well.
andrew
-
I think the node that actually controls the leds would need to be using S_DIMMER but you probably would only need to use S_BINARY for the wireless remote to control the feedback leds.
You could then just send node to node messages to the dimmer module for on/off or dimmer level and the dimmer module would send back the status for your feedback leds.
-
I think the node that actually controls the leds would need to be using S_DIMMER but you probably would only need to use S_BINARY for the wireless remote to control the feedback leds.
You could then just send node to node messages to the dimmer module for on/off or dimmer level and the dimmer module would send back the status for your feedback leds.
-
You will be able to send node to node without the controller but I do not think node to node will work without the gateway, on 2.1.1 at least. There have been posts on this issue before, not sure if the development branch has moved forward on this.
Node to node communication fails if gateway is not reachable
(Almost) Controller-Less MySensors switch/light network
The other problem you will face will be trying to keep your remote switch node in sync with the led control node. This will be easy enough to do when the network is fully working but becomes harder if one or more of the nodes does not receive a message when it is sent.
Some other posts that may be of interest, showing node to node and requesting node status.
AC Power controller with node to node remotes
Outdoors Touch Switch light controller
The only way I can think of that will absolutely guarantee control of the lights at all times is to have the switching mechanism directly wired to the lamp controller. Like in this example
-
You will be able to send node to node without the controller but I do not think node to node will work without the gateway, on 2.1.1 at least. There have been posts on this issue before, not sure if the development branch has moved forward on this.
Node to node communication fails if gateway is not reachable
(Almost) Controller-Less MySensors switch/light network
The other problem you will face will be trying to keep your remote switch node in sync with the led control node. This will be easy enough to do when the network is fully working but becomes harder if one or more of the nodes does not receive a message when it is sent.
Some other posts that may be of interest, showing node to node and requesting node status.
AC Power controller with node to node remotes
Outdoors Touch Switch light controller
The only way I can think of that will absolutely guarantee control of the lights at all times is to have the switching mechanism directly wired to the lamp controller. Like in this example
-
by browsing the API documentation I did not find mapping details between the message type enums and their corresponding data representing format.
so, from where should I know that e.g. V_PERCENTAGE messages needs uint8_t and not anything else? as I see it is possible to send any data format for any message type.if I have to handle the messages between my nodes then it is not that problematic, but if it has to be forwarded to the controller then it would be nice to have it standardized.
-
by browsing the API documentation I did not find mapping details between the message type enums and their corresponding data representing format.
so, from where should I know that e.g. V_PERCENTAGE messages needs uint8_t and not anything else? as I see it is possible to send any data format for any message type.if I have to handle the messages between my nodes then it is not that problematic, but if it has to be forwarded to the controller then it would be nice to have it standardized.
@andrew said in which sensor and msg type for switch/dimmer node (sender only)?:
by browsing the API documentation I did not find mapping details between the message type enums and their corresponding data representing format.
so, from where should I know that e.g. V_PERCENTAGE messages needs uint8_t and not anything else? as I see it is possible to send any data format for any message type.I have not seen a list , there was a post that asked the same thing but it did not seem to go anywhere.
if I have to handle the messages between my nodes then it is not that problematic, but if it has to be forwarded to the controller then it would be nice to have it standardized.
If I am unsure I usually just get the data type from the serial data during construction/testing. Just look at the send data, the payload type (pt) will be shown there. The send message below for a binary device shows pt=1 which is a byte.
TSF:MSG:SEND,233-233-0-0,s=1,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:1
The definitions for pt are
P_STRING = 0, P_BYTE = 1, P_INT16 = 2, P_UINT16 = 3, P_LONG32 = 4,
P_ULONG32 = 5, P_CUSTOM = 6, P_FLOAT32 = 7Be mindful that the receive message is different:
TSF:MSG:READ,0-0-233,s=1,c=1,t=2,pt=0,l=1,sg=0:0
You can see the message sent from the controller for the same switch arrives as pt=0 which is a string.
You can also use the handy Log Parser to decode the serial data. here is the readout for the previous two lines.
-
@andrew said in which sensor and msg type for switch/dimmer node (sender only)?:
by browsing the API documentation I did not find mapping details between the message type enums and their corresponding data representing format.
so, from where should I know that e.g. V_PERCENTAGE messages needs uint8_t and not anything else? as I see it is possible to send any data format for any message type.I have not seen a list , there was a post that asked the same thing but it did not seem to go anywhere.
if I have to handle the messages between my nodes then it is not that problematic, but if it has to be forwarded to the controller then it would be nice to have it standardized.
If I am unsure I usually just get the data type from the serial data during construction/testing. Just look at the send data, the payload type (pt) will be shown there. The send message below for a binary device shows pt=1 which is a byte.
TSF:MSG:SEND,233-233-0-0,s=1,c=1,t=2,pt=1,l=1,sg=0,ft=0,st=OK:1
The definitions for pt are
P_STRING = 0, P_BYTE = 1, P_INT16 = 2, P_UINT16 = 3, P_LONG32 = 4,
P_ULONG32 = 5, P_CUSTOM = 6, P_FLOAT32 = 7Be mindful that the receive message is different:
TSF:MSG:READ,0-0-233,s=1,c=1,t=2,pt=0,l=1,sg=0:0
You can see the message sent from the controller for the same switch arrives as pt=0 which is a string.
You can also use the handy Log Parser to decode the serial data. here is the readout for the previous two lines.
@boots33 I'm looking for some expect data type declaration / enforcement for the given value types. e.g. due to a mistake in my code, nothing prevented me to send 2 bytes uint16_t payload for the V_PERCENTAGE. so, the msg setters basically do not care about the msg type vs payload type/length validation, which could cause inconsistency or improperly used communication.
this causes my problem at the receiver side as well, because data type is not enforced for the given msg/value type.
this is how I see it now, maybe there are proper solutions for this.
-
@boots33 I'm looking for some expect data type declaration / enforcement for the given value types. e.g. due to a mistake in my code, nothing prevented me to send 2 bytes uint16_t payload for the V_PERCENTAGE. so, the msg setters basically do not care about the msg type vs payload type/length validation, which could cause inconsistency or improperly used communication.
this causes my problem at the receiver side as well, because data type is not enforced for the given msg/value type.
this is how I see it now, maybe there are proper solutions for this.
@andrew At the moment any data enforcing you require will need to be coded in your sketch and as I have said there are ways to determine the data type required.
I am not sure as to why it is not present in the MySensors library, it may be worthwhile to start another thread on this and see what other information you can get.
