Why I quit using MySensors for actuators
-
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.
@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.
http://yveaux.blogspot.nl
-
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.
-
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 :)@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.
-
@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.
@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 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.
@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.
-
@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.
@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.C: OpenHAB2 with node-red on linux laptop
GW: Arduino Nano - W5100 Ethernet, Nrf24l01+ 2,4Ghz mqtt
GW: Arduino Mega, RFLink 433Mhz -
@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.@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?
-
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 :)C: OpenHAB2 with node-red on linux laptop
GW: Arduino Nano - W5100 Ethernet, Nrf24l01+ 2,4Ghz mqtt
GW: Arduino Mega, RFLink 433Mhz -
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 :)@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?
-
@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?
@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...
http://yveaux.blogspot.nl
-
@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...
@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 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?
@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 :smiling_imp: -
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,
SJupdate 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.
-
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.
-
@NeverDie that sounds promising. Is there a document/ discussion available on the details?
@parachutesj
Not that I know of. -
@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.
@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. -
@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.
