Why I quit using MySensors for actuators
-
@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.
-
@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.
