Why I quit using MySensors for actuators
-
@DavidZH
I am using this:With ESPeasy loaded in it.
I am using "Rules" from ESPeasy and send messages directly between nodes, so when my Domoticz goes off, switches and relays still works. When wi-fi is down, switch still works locally.
Each relays send notification about his state to the controller ( Domoticz ) and Domoticz send messages to the relay like other nodes.Thanks, but I try to stay away from 2.4GHz for my home automation. I live in an apartment building with 160 units and our main ISP is kind enough to supply modem/router boxes packed with wifi. Needless to say that the ether is crowded here.
Plus we (as in me and my better half) do not like the design of those switches as we prefer feedback ("click").
-
In the past storms season, our garage door board fried, so I replaced it with a new one using mysensors.
It has double power supply, the door motor is on its isolated own.
But I was having this strange behaving. Sometimes when opening or closing the door, it will stop after some centimeters. Then with my click it will go back until completely open or closed. That's strange alone, but in some cases, it will then start again without command and do the complete travel. Coming from an stop interrupt that would be impossible.
Also, if I insisted clicking or stopped this movement it ended in the gateway being hung and I had to restart it along with the rpi.I thought it was caused by duplicate orders sent back by controller, echoes or so, So I Incorporated two things:
While travelling, it doesn't do anything more. Nothing is sent back to controller.
And, after an order is received, decline all to follow for 1-2sec.The door now behaves immaculate, without any fail or hesitation. The gateway hasn't hung since the change.
-
In the past storms season, our garage door board fried, so I replaced it with a new one using mysensors.
It has double power supply, the door motor is on its isolated own.
But I was having this strange behaving. Sometimes when opening or closing the door, it will stop after some centimeters. Then with my click it will go back until completely open or closed. That's strange alone, but in some cases, it will then start again without command and do the complete travel. Coming from an stop interrupt that would be impossible.
Also, if I insisted clicking or stopped this movement it ended in the gateway being hung and I had to restart it along with the rpi.I thought it was caused by duplicate orders sent back by controller, echoes or so, So I Incorporated two things:
While travelling, it doesn't do anything more. Nothing is sent back to controller.
And, after an order is received, decline all to follow for 1-2sec.The door now behaves immaculate, without any fail or hesitation. The gateway hasn't hung since the change.
-
@Sergio-Rius I have a similar behaviour with 2 of my relay actuators. Could you share your sketch?
@korvad The sketch is a mess and I'm sure what I'm doing with 4 relays could be made with only two, but the changes I incorporated where basically:
void loop() { refreshStatus(); // Don't do anything else during movement if (CurrentStatus == GOINGUP || CurrentStatus == GOINGDOWN) return; ...And in receive:
void receive(const MyMessage &message) { static uint32_t next_cmd = 0; switch (message.type) { case V_STATUS: if (message.sensor == CHILD_ID_TOGGLE) { #ifdef _DEBUG DEBUGPLN("*** RECEIVED TOGGLE *************************"); #endif // Avoid controller command echoes. const uint32_t now = millis(); if (PENDING(now, next_cmd)) { #ifdef _DEBUG DEBUGPLN("Too much commands in a short while! Ignoring."); #endif return; } next_cmd = now + MIN_RX_INTERVAL; ... -
@korvad The sketch is a mess and I'm sure what I'm doing with 4 relays could be made with only two, but the changes I incorporated where basically:
void loop() { refreshStatus(); // Don't do anything else during movement if (CurrentStatus == GOINGUP || CurrentStatus == GOINGDOWN) return; ...And in receive:
void receive(const MyMessage &message) { static uint32_t next_cmd = 0; switch (message.type) { case V_STATUS: if (message.sensor == CHILD_ID_TOGGLE) { #ifdef _DEBUG DEBUGPLN("*** RECEIVED TOGGLE *************************"); #endif // Avoid controller command echoes. const uint32_t now = millis(); if (PENDING(now, next_cmd)) { #ifdef _DEBUG DEBUGPLN("Too much commands in a short while! Ignoring."); #endif return; } next_cmd = now + MIN_RX_INTERVAL; ... -
Were you previously debouncing the button press? Also, is the module on the same electrical circuit as the garage door motor? I wonder whether it's a power/noise isolation issue that comes into play because of the heavy motor.
-
@Sergio-Rius Can you explain why you send a toggle to the door instead of up or down?
A toggle message that is received multiple times will move the door in an arbitrary direction...@Yveaux I initially have it designed for open/close commands. But I was having too much trouble with sync when messages where lost.
Now it simply ignores the type of command and relies more on controlling its own state.
That's the complex part of the sketch.
But it works as factory default. -
Were you previously debouncing the button press? Also, is the module on the same electrical circuit as the garage door motor? I wonder whether it's a power/noise isolation issue that comes into play because of the heavy motor.
@NeverDie it doesn't have any physical button. It's always actuated through the controller.
Also the door motor is on a completely separated circuit. Has its own PSU (ac) and it's independently activated with relays through opto-isolators.
It cuts motor power when it's not used.Don't miss understand, is working very well. I only presented it as an example for an actuator that was giving trouble but that was made to work.
-
@NeverDie it doesn't have any physical button. It's always actuated through the controller.
Also the door motor is on a completely separated circuit. Has its own PSU (ac) and it's independently activated with relays through opto-isolators.
It cuts motor power when it's not used.Don't miss understand, is working very well. I only presented it as an example for an actuator that was giving trouble but that was made to work.
@Sergio-Rius said in Why I quit using MySensors for actuators:
independently activated with relays through opto-isolators
If I'm not mistaken, relay contacts can bounce too, just like a button. Well, anyway, just water under the bridge at this point it sounds like.
-
@korvad The sketch is a mess and I'm sure what I'm doing with 4 relays could be made with only two, but the changes I incorporated where basically:
void loop() { refreshStatus(); // Don't do anything else during movement if (CurrentStatus == GOINGUP || CurrentStatus == GOINGDOWN) return; ...And in receive:
void receive(const MyMessage &message) { static uint32_t next_cmd = 0; switch (message.type) { case V_STATUS: if (message.sensor == CHILD_ID_TOGGLE) { #ifdef _DEBUG DEBUGPLN("*** RECEIVED TOGGLE *************************"); #endif // Avoid controller command echoes. const uint32_t now = millis(); if (PENDING(now, next_cmd)) { #ifdef _DEBUG DEBUGPLN("Too much commands in a short while! Ignoring."); #endif return; } next_cmd = now + MIN_RX_INTERVAL; ...@Sergio-Rius thx, will try to adapt your sketch to my needs.
-
@Sergio-Rius said in Why I quit using MySensors for actuators:
independently activated with relays through opto-isolators
If I'm not mistaken, relay contacts can bounce too, just like a button. Well, anyway, just water under the bridge at this point it sounds like.
@NeverDie As the relays only activate the main motor power supply and controls start&stop and direction, bouncing is not a problem.
Perhaps you where thinking on an arduino actuating the door mechanism button? -
@dakipro said in Why I quit using MySensors for actuators:
I understand the principle, number of sent packets should match number of received ones per node :)
I thought it was perhaps already implemented on node/gateway level. I guess one could always send Text or some custom label and handle it in controller, but having it integrated in gateway itself would be awesome :)wait, what?
I thought MySensors already implemented this! It doesn't?
I want to use mysensors to turn a heater on and off. That's serious stuff. I thought MySensors went beyond 433 stuff because if made sure that messages arrived?
-
@dakipro said in Why I quit using MySensors for actuators:
I understand the principle, number of sent packets should match number of received ones per node :)
I thought it was perhaps already implemented on node/gateway level. I guess one could always send Text or some custom label and handle it in controller, but having it integrated in gateway itself would be awesome :)wait, what?
I thought MySensors already implemented this! It doesn't?
I want to use mysensors to turn a heater on and off. That's serious stuff. I thought MySensors went beyond 433 stuff because if made sure that messages arrived?
@alowhum if you use ACK you know if message arrived or not. MySensors will resend message a few times if it fails (there's a #define for this I think) but not forever. If it's critical you can handle the false when it's returned in your code and resend the message after a little delay, and send yourself a warning/alert in the end if the node is unreachable).
-
@alowhum if you use ACK you know if message arrived or not. MySensors will resend message a few times if it fails (there's a #define for this I think) but not forever. If it's critical you can handle the false when it's returned in your code and resend the message after a little delay, and send yourself a warning/alert in the end if the node is unreachable).
-
@nca78 Thanks for the explananation! Do you perhaps know of an example sketch that has good example code for this? I haven't come accross it.
-
@alowhum I made a test with the scipt of a remote control switch. I will look for it but it's really not some advanced programming :)
-
Hi, I know I'm a little late to this thread. I'm just starting with MySensors and am learning by reading the posts.
Currently I am waiting for hardware for my 1st gateway so I am not encumbered by details.
I notice in all the reported cases the "problem" node is AC powered, while many of the "good" sensor nodes are battery powered. Could this be significant? It would be interesting if someone with a "problem" actuator node could put a battery operated sensor node in the same area.
Just a thought.
-
Hi, I know I'm a little late to this thread. I'm just starting with MySensors and am learning by reading the posts.
Currently I am waiting for hardware for my 1st gateway so I am not encumbered by details.
I notice in all the reported cases the "problem" node is AC powered, while many of the "good" sensor nodes are battery powered. Could this be significant? It would be interesting if someone with a "problem" actuator node could put a battery operated sensor node in the same area.
Just a thought.
@johnrob said in Why I quit using MySensors for actuators:
Hi, I know I'm a little late to this thread. I'm just starting with MySensors and am learning by reading the posts.
Currently I am waiting for hardware for my 1st gateway so I am not encumbered by details.
I notice in all the reported cases the "problem" node is AC powered, while many of the "good" sensor nodes are battery powered. Could this be significant? It would be interesting if someone with a "problem" actuator node could put a battery operated sensor node in the same area.
Hello,
the problem is an actuator node has to listen to the radio constantly and can't sleep, so it can't last long on batteries...
