Why I quit using MySensors for actuators

[parachutesj]

It's been a while since I started with MySensors and had quite some troubles and eventually figured everything out. In the meantime I have a lot of sensors all over the place but I am a bit biased about the results.

One one side, all the sensors (door, window, temp, sun, water, humitdity etc) they work flawless. I have some very low power sensors on batteries which run "forever" and they update quite frequent and once started they just do what they need to do: send sensor data to my gateway. Perfect!
As a sensor platform, I am very happy with the results.
On the other side, I also have a few actuators. Mainly rollershutters, a few LED-dimmers and light switches.
As the light and dimmers (mostly) work, the results with the rollershutters are bad. First the good part: I do have two window motors in quite remote places, they work. Built with relays for up/down movement. No troubles.
Then a few other rollershutters which are actually quite close to the gateway, they fail. every now and then the signal from gateway fails. I do not know why. I have changed everything in the meantime: Antennas, radios, power supplys, relais, arduinos, new circuits, other electronic parts (first a bunch of Nanos, then proMini) nothing gives reliable results. I tried to tweak the software as best as it goes, added sensors to send "alive" messages like temperature but then again after one day or one week or two weeks, it fails again. sometimes I only need to trigger a manual switch to get it back, then I have to power cycle.
So after more than one year, I am done with testing. I need to get something stable now. Moving on...

Some facts:
I use NRF24 radios, maybe others would deliver better results. But I am not willing to waste another year.
I am on latest stable release.
My gateway has been changed as well. Currently an "official" arduino Uno with amplified radio and external 10A power supply to have enough juice.
I am doing electronics since many years, but no expert but think I know mostly what I am doing.

Thank you for all your help, will stick around for additional sensor only devices, as this seems to work (for me).

Cheers,
SJ

[mfalkvidd]

@parachutesj Thanks for your feedback. It would be great if you could share your experience of the new technology when you have moved on and gotten some experience with it (whatever technology you may choose). Maybe there can be some lessons to learn and solutions to be inspired by.

[erangaj]

I have the exact same problem with actuators. I tried my best to resolve the issue just like parachutesj but finally gave up mysensors for actuators and replaced them with wifi connected esp8266s. MySensors is still great for sensors, especially battery powered ones.

[dbemowsk]

How are you connecting these actuators? What type of actuator is it? Maybe you need some kind of different coupling to your actuator circuit. Motor type actuators can create a lot of noise and if not properly filtered can cause issues.

[Nca78]

Hello,

maybe a stupid question, but are they not too close to the gateway using a PA LNA ?
Did you try a second gateway on a different channel with a non amplified module to connect those failing roller shutters ?

[parachutesj]

@erangaj that's the way I want to try... as the actuators are connected to the mains anyway the power consumption is not the major issue here. Thanks for your feedback

[parachutesj]

@Nca78 that could be an issue, I totally agree. However when I started I did not use the amplified radio and my first 3 nodes which are in fact the closer ones (4-8m from gateway) showed similar behaviour why I got the PA radio.
Not sure if this would explain that it works for a while and then stops.
So it might be an issue, but then again I tried so much already and if it is so sensitive in the end, it is not the right and failure proof thing I want. I am not out of MySensors, just for actuators.

[parachutesj]

@dbemowsk that could also be an issue. The relays are used to drive rollershutters. They are not connected directly to the I/O pins, always via transistors. Self-designed circuits and China-boards like below. (btw: Power does not seem to be an issue)
But why do some locations work and others don't? The relay boards, the arduinos, power supplies etc seem not to be the issue as I have exchanged them over time. Even one lamp with a relay which is connected directly and in fact was just a proof of concept works flawless since over a year.

Don't get me wrong, I've learned a lot and it is fun building things. I will continue with sensors, maybe return for actuators. But as I (with my limited skills and measure equipment) got to a point where I am not getting the reliable results I would had hoped, I look into another technology which might be better (simpler) for me (hopefully).

Aliexpress relay

[rollercontainer]

My communication problems vanished by exchanging the amplified version by a normal NRF24.

[erangaj]

I used relays. Most commands sent to actuators resulted in NACKs. But sensors were fine. I have tested different Arduinos, nrfs, circuits with an RPi gateway as well as a serial Arduino gateway with no luck. Problem temporary goes away when the gateway is restarted. This is true for both RPi and serial gateways.

[wallyllama]

In the days of analog tv/radio dead spots and multipath were easy to detect. Digital isnt as susceptable to multipath, but isn't completely immune either. An rf field meter might help. Directional antennas probably will help. If these nrf devices can measure rssi it may be good to hook up and led as a signal quality indicator of some sort. It sounds like you have a strong signal near the problem, could be overloading the receiver, could be IM ( intermodulation, not instant messaging). It could be an rf shield on all but the antenna may help.

My sensors may have some of this already, if so ignore me, Im using rs485.

Note to self, check if "myactuators.org" is available.

Filter caps on the actuators? I think someone mentioned this, they can be a source of noise in the power, or rf hashing.

An rtl_sdr sort of device might be a cheap rf signal analyser.

[parachutesj]

@wallyllama I appreciate your help and also the help from the others on this thread, I really do.
And I also still hope to find the root cause some day. However as you mentioned it is no straight forward and there are so many components and variables I might never been able to have a stable environment even after so many tests I did (see above).
For the moment I stopped building new actuators based on MySensors, I switched to ESP. There are challenges but not so much on the radio side. I actually wanted to avoid having them in my WLAN why I started with MyS in first place but for the moment it looks like they just work. It is only a few days so need to wait to come to a result.

For sensors, I am still building on MyS, have recently deployed a few more temp/hum sensors with coin cells. Still impressed with the low power consumption.

[msmacs]

@parachutesj
Hi,
nrf24 radios share the same frequencies of wifi spot.
Did you check the presence of any WiFi spot, repeater or any other source of signal that could interfer with nrf24 modules?
You could check the Wifi spectrum with your smartphone. There are a lot of apps that analyze the frequencies.
Just an example: https://play.google.com/store/apps/details?id=cz.webprovider.wifianalyzer

[wallyllama]

@parachutesj so I mostly just spewed random thoughts, And looking at them again I came up with some more focused, probably not original, ideas.

Some kind of watchdog/debug output is needed on actuator type nodes(may already exist)

Rtl_sdr dongles are cheap and some signal analysis tools exist. Someone that knows what they are doing (not me, I just have a big mouth) could probably cook up some useful tutorial that would shed light on what looks to me like the biggest issue in mysensors, signal reliability.

[parachutesj]

@msmacs did that, changed channels a few times, even the ones which are not so legal here to test but haven't seen any positive effects.

[DavidZH]

@parachutesj I can see why you chose to move away. RF will always be in the "black magic" realm. Unable to see, hear or feel it's presence. Of course with the proper tools, and knowledge of the correct use of aforementioned tools a lot can be unveiled, but those are out of reach for the average hobbyist.

I have stopped working on actuators as a safety precaution. Most lights I want to operate are fixed lights, and the in-wall-boxes where I'd have to put the actuators are just too small to be able to fit both my own design MySensors actuator and a momentary switch. One must in my system is the ability to switch the light locally for whenever the controller or network fails.
The final push for me to walk away was a fire at a family members house caused by a cheap china power supply. No one was hurt, but it took 4 weeks before the family could move back in. I just felt I was not capable of designing a safe power supply to power the node, that would fit inside the wall box.
So Z-wave it is. With a lot of compatibility issues. But I use it just for communications, not the think-work.

So I will also stay here for the input part. Sensors galore.... And there will be an actuator later. A low voltage dimmer. Max 30V DC input. Let other people worry about the mains side of things. I just cant bear the thought of putting my family in jeopardy because I wanted a hobby so hard.

[NeverDie]

I wonder if there might be some source of interference that's affecting the actuators? Have you tried a quieter channel to see if it makes any difference?

[parachutesj]

@NeverDie I do not have the tools to analyze this. I checked the information from the router and there was a sketch scanning the frequencies which I tried and picked a channel which seems to be ok. After a while I changed is to 2 or 3 different values with similar results. Changing it again will be painful.

[petewill]

I realize this thread is getting old but I'm behind in my reading...

I just wanted to say that I have been using actuators (irrigation, lighting, motors, etc) for years and I have had nearly flawless results (at least as good as my z-wave stuff, if not better). I don't want to start any arguments but just wanted to let everyone know that it is possible to use MySensors for actuators in case you haven't tried it. I'm actually pretty surprised that people seem to be having issues with actuators as mine have been working well.
I did find that modifying the NRF antennas as well as using repeaters has helped in some of the devices that are far away from my gateway.
Hopefully this doesn't come across the wrong way, just wanted to give some encouragement to not give up

[NeverDie]

The real question is: why would there be any difference in reliability between a sensor and an actuator? In both cases, it's just a radio link, right? Unless maybe the actuator might do something (voltage spike from a motor maybe?) to put the radio/mcu into some undefined state. In that case, would doing a hard reset on the radio after each actuation keep it in line?

Or is it more the case that we're more likely to notice an actuator fault than a sensor fault? e.g. If you miss a particular temperature measurement, odds are there will be another one coming along shortly--and you have the measurement you took a few minutes earlier to fall back on. But if you want to roll up the shades, and it doesn't happen when you command it, then that's admittedly more irritating.

[Yveaux]

@NeverDie said in Why I quit using MySensors for actuators:

we're more likely to notice an actuator fault than a sensor fault?

Judging from recent measurements I'm quite sure this is the cause. Especially a wireless actuator switched by a wireless sensor requires 2 succesful message transmissions. If one of them fails you will notice immediately.

To make things worse, sensors often only transmit a new value if it changed w.r.t. the previous one. If an isochronal sensor skips a sensor value at the gateway, we'll never know if it just didn't send the value because it was identical to the previous one, or if a new value wasn't received.

[sundberg84]

I had 3 switches for window lights(pro mini 5v, arduino relay) and they worked flawless! (Anything else and my wife would unplug them). I moved away because of security (240 to 5v before HLK discussion.) but never had any issues with reception/radio or missed commands.

It is possible to do with MySensors and with my small experience in the forum many posts seems to be about power issues/interference actuator vs radio/power.

There are one situation I'm not sure about which I have not been able to test and that is using actuator with a repeater in between... but I will soon have the logging possibilities for gw/repeater and actuator at the same time.

[parachutesj]

@petewill don't get me wrong, I love this project and impressed by all the positive things. It is just that I - with my limited skills and resources - not able to get a decent stable state. I wan't it to be perfect.

[parachutesj]

@Yveaux I wan't to believe this. However the sensors recover. IF it fails once, and then send again 5 mins later and it is successful - I guess most of us can live with this. E.g. I do have a rain sensor which sends via interrupt changed state. So as soon as it starts raining I get the update and close my roof windows. This NEVER failed. So I would say even if I do not know if some measurements are getting lost - I never noticed it. Also the other sensors seem quite stable.

But as @NeverDie said, when an actuator fails, the light is not on etc. and you notice it immediately. The strange thing is, when they fail, they hardly recover themselves. Sometimes it works, sometime it doesn't.

So for my rollershutters, in my rules from home automation (openHAB), I always send a "STOP" before reducing the chance that the next comand fails. This helped a lot but is just a workaround and not helping always. And then there are the situations, when they seem to "lock" and nothing helps and as soon as I press a physical button, it is working again (or do a arduino reset).
I also debugged it and had the serial connected while that happend but it looked like no signal arrived at the node. So it failed somewhere in between.

I think it could be the whole setup of the gateway. Either power supply, arduino, antenna, powermode or the alignment... but why happens it only on some nodes and not on others? And I have changed basically everything in the meantime.

I just don't have the energy at the moment to further research on the topic. Appreciate your comments and suggestions

[NeverDie]

@Yveaux said in Why I quit using MySensors for actuators:

To make things worse, sensors often only transmit a new value if it changed w.r.t. the previous one. If an isochronal sensor skips a sensor value at the gateway, we'll never know if it just didn't send the value because it was identical to the previous one, or if a new value wasn't received.

That's where there's value in numbering your packets and having the gateway keep track of how many aren't received. Your statement is still true, but at least over time you develop statistics about how (un)reliable the connection is, so you can be as pro-active as you want to be in fixing it.

[dakipro]

@NeverDie said in Why I quit using MySensors for actuators:

numbering your packets and having the gateway keep track of how many aren't received

Hi, could you elaborate this a bit more, maybe with some link/example about how to number the packages, and how to keep track of them on the gateway?
I am also very interested in this statistics, as a way to improve long term reliability.

[NeverDie]

@dakipro said in Why I quit using MySensors for actuators:

@NeverDie said in Why I quit using MySensors for actuators:

numbering your packets and having the gateway keep track of how many aren't received

Hi, could you elaborate this a bit more, maybe with some link/example about how to number the packages, and how to keep track of them on the gateway?
I am also very interested in this statistics, as a way to improve long term reliability.

I haven't actually done it yet, but I believe it's a common technique employed for, say, knowing whether different packets are meant to be the same packet or not (for instance, a retransmitted packet because a node never got an ACK). In fact, I think 802.15.4 may include a byte in the frame for this purpose.

But, the idea is simple, so let's think it through anyway. Suppose you only send temperature packets if there has actually been a change in temperature since the last packet. Also, assume no ACKing. Well, the fact is not every packet may get through. So, the gateway may not be up-to-date on what the current temperature is.

Now, suppose you include a byte in the payload as a counter. Every time the mote sends a new temperature, it increments the counter. The gateway knows the last packet it received, and so it compares that counter to the next packet it receives. newCounter should be oldCounter+1, right? If, instead, it's oldCounter+2, then the gateway knows that a packet was sent that it didn't receive.

Get it?

[dakipro]

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

[NeverDie]

@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

If it's something you want, maybe you can request it?

[Yveaux]

@NeverDie said in Why I quit using MySensors for actuators:

Now, suppose you include a byte in the payload as a counter.

Let's go all the way then and implement 'guaranteed delivery', not a diagnostic counter that only tells you your connection sucks...

[NeverDie]

@Yveaux said in Why I quit using MySensors for actuators:

@NeverDie said in Why I quit using MySensors for actuators:

Now, suppose you include a byte in the payload as a counter.

Let's go all the way then and implement 'guaranteed delivery', ...

How does one do that?

[Yveaux]

@NeverDie Simple said: Buffer messages at nodes until they receive an acknowledge that the message was delivered succesfully. Retry sending the message after some time if the acknowledge does not arrive.
The principle is simple, but the devil is in the details

[parachutesj]

update on my above post:
Another node started to act crazy, had to restart it several times (simple relay with one lamp attached). Then my gateway failed shortly after. I had to restart everything. By chance I realigned the antenna and since then all runs quite stable. This drives me crazy...

Regarding the "new" solution I am currently trying: Exchanged one of the problematic nodes with a Wemos D1 mini. Runs without any issue since 2 months.

[NeverDie]

Just a thought, but have you tried using two (or more) gateways, spaced half a wavelength apart from one another? Maybe that would help with your reliability.

[parachutesj]

@NeverDie that sounds promising. Is there a document/ discussion available on the details?

[NeverDie]

@parachutesj
Not that I know of.

[kimot]

@DavidZH
I am using this:

Sonoff Touch

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.

[DavidZH]

@kimot

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").

[Sergio Rius]

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.

[korvad]

@Sergio-Rius I have a similar behaviour with 2 of my relay actuators. Could you share your sketch?

[Sergio Rius]

@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;
...

[Yveaux]

@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...

[NeverDie]

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]

@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.

[Sergio Rius]

@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]

@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]

@Sergio-Rius thx, will try to adapt your sketch to my needs.

[Sergio Rius]

@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?

[alowhum]

@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?

[Nca78]

@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]

@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.

[Nca78]

@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

[alowhum]

@nca78 Well, anything is helpful! Thanks!

[JohnRob]

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.

[Nca78]

@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...