There is a problem with the example code for RelayActuator.ino It is not checking for ACK messages. See the other example called SecureActuator.ino that does this. Without checking for ACK messages my relay gets an ON signal and turns on then immediately thereafter gets an ACK signal for V_STATUS command which is assumed in this example to be a control and the value is "0" so it turns off the relay.
It appears this project is not really active anymore, but if anyone is interested here is a node red flow you can use to allow MYSController to use MQTT - with OTA updates (MYSBootloader)
In MYSController setup to use TCP on port 8164 (or choose another in Node red).
Then click "Discover" and everything should then start streaming in.
[{"id":"05daaa30f133dea6","type":"tab","label":"MYSController Bridge","disabled":false,"info":"","env":[]},{"id":"0c03db96217a8d15","type":"tcp in","z":"05daaa30f133dea6","name":"","server":"server","host":"","port":"8164","datamode":"stream","datatype":"utf8","newline":"","topic":"","trim":false,"base64":false,"tls":"","x":120,"y":160,"wires":[["207a2bef4ba58466"]]},{"id":"b216b0fc146f38d6","type":"mqtt out","z":"05daaa30f133dea6","name":"To mygateway1-in","topic":"","qos":"","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"6da0af37c3ba3336","x":670,"y":160,"wires":[]},{"id":"207a2bef4ba58466","type":"function","z":"05daaa30f133dea6","name":"function 1","func":"flow.set("tcp_session",msg._session);\nflow.set("tcp_ip",msg._session);\nflow.set("tcp_port",msg._session);\nvar parts = msg.payload.split(";");\nmsg.topic = "mygateway1-in" + '/' + parts[0] + '/' + parts[1] + '/' + parts[2] + '/' + parts[3] + '/' + parts[4];\nmsg.payload = parts[5];\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":380,"y":160,"wires":[["b216b0fc146f38d6"]]},{"id":"e97f3f15b6b5c04f","type":"mqtt in","z":"05daaa30f133dea6","name":"From myqateway1-out","topic":"mygateway1-out/#","qos":"2","datatype":"utf8","broker":"6da0af37c3ba3336","nl":false,"rap":true,"rh":0,"inputs":0,"x":160,"y":240,"wires":[["aa75b302916ca68b"]]},{"id":"7f06f63ff068402c","type":"tcp out","z":"05daaa30f133dea6","name":"","host":"","port":"8164","beserver":"reply","base64":false,"end":false,"tls":"","x":640,"y":240,"wires":[]},{"id":"aa75b302916ca68b","type":"function","z":"05daaa30f133dea6","name":"function 2","func":"msg._session = flow.get("tcp_session");\nmsg.ip = flow.get("tcp_ip");\nmsg.port = flow.get("tcp_port");\nif (msg._session == undefined)\n return null;\nvar parts = msg.topic.split("/");\nmsg.payload = parts[1] + ';' + parts[2] + ';' + parts[3] + ';' + parts[4] + ';' + parts[5] + ';' + msg.payload + "\n";\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":400,"y":240,"wires":[["7f06f63ff068402c"]]},{"id":"6da0af37c3ba3336","type":"mqtt-broker","name":"OLD MYC PI","broker":"192.168.1.6","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]
For some reason I am now unable to reproduce the issue on the standard RelayActuator.ino example. It was definitely sending ACK requests when I was testing a few days ago. I have subsequently updated MySensors library and also MyController to their latest Snapshot - so perhaps the issue comes up under one of those scenarios.
The issue around this though is that the example does not report the current status of the relay in the loop. My own sketch was doing so. I guess many people take an example and modify it like I do. Therefore copying the example and adding in the code to send the current relay status periodically means the receive function will not work properly due to the Ack messages received,
I would then suggest adding a note to the receive function of the relay example sketch to say that "if your node sends messages then you need to check for Ack and discard those messages" - or something along those lines. This will help !
It appears this project is not really active anymore, but if anyone is interested here is a node red flow you can use to allow MYSController to use MQTT - with OTA updates (MYSBootloader)
In MYSController setup to use TCP on port 8164 (or choose another in Node red).
Then click "Discover" and everything should then start streaming in.
[{"id":"05daaa30f133dea6","type":"tab","label":"MYSController Bridge","disabled":false,"info":"","env":[]},{"id":"0c03db96217a8d15","type":"tcp in","z":"05daaa30f133dea6","name":"","server":"server","host":"","port":"8164","datamode":"stream","datatype":"utf8","newline":"","topic":"","trim":false,"base64":false,"tls":"","x":120,"y":160,"wires":[["207a2bef4ba58466"]]},{"id":"b216b0fc146f38d6","type":"mqtt out","z":"05daaa30f133dea6","name":"To mygateway1-in","topic":"","qos":"","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"6da0af37c3ba3336","x":670,"y":160,"wires":[]},{"id":"207a2bef4ba58466","type":"function","z":"05daaa30f133dea6","name":"function 1","func":"flow.set("tcp_session",msg._session);\nflow.set("tcp_ip",msg._session);\nflow.set("tcp_port",msg._session);\nvar parts = msg.payload.split(";");\nmsg.topic = "mygateway1-in" + '/' + parts[0] + '/' + parts[1] + '/' + parts[2] + '/' + parts[3] + '/' + parts[4];\nmsg.payload = parts[5];\nreturn msg;","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":380,"y":160,"wires":[["b216b0fc146f38d6"]]},{"id":"e97f3f15b6b5c04f","type":"mqtt in","z":"05daaa30f133dea6","name":"From myqateway1-out","topic":"mygateway1-out/#","qos":"2","datatype":"utf8","broker":"6da0af37c3ba3336","nl":false,"rap":true,"rh":0,"inputs":0,"x":160,"y":240,"wires":[["aa75b302916ca68b"]]},{"id":"7f06f63ff068402c","type":"tcp out","z":"05daaa30f133dea6","name":"","host":"","port":"8164","beserver":"reply","base64":false,"end":false,"tls":"","x":640,"y":240,"wires":[]},{"id":"aa75b302916ca68b","type":"function","z":"05daaa30f133dea6","name":"function 2","func":"msg._session = flow.get("tcp_session");\nmsg.ip = flow.get("tcp_ip");\nmsg.port = flow.get("tcp_port");\nif (msg._session == undefined)\n return null;\nvar parts = msg.topic.split("/");\nmsg.payload = parts[1] + ';' + parts[2] + ';' + parts[3] + ';' + parts[4] + ';' + parts[5] + ';' + msg.payload + "\n";\nreturn msg;\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":400,"y":240,"wires":[["7f06f63ff068402c"]]},{"id":"6da0af37c3ba3336","type":"mqtt-broker","name":"OLD MYC PI","broker":"192.168.1.6","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willRetain":"false","willPayload":"","willMsg":{},"userProps":"","sessionExpiry":""}]
@zboblamont Are you "ghost levels" not perhaps echoes bouncing around the tank and nothing in the tank to absorb the sound quickly. If so perhaps increasing time between pings might help to let the previous ping dissipate.
@zboblamont Yes - that spec sheet does say "1,10uS above the TTL pulse". That is not a great english translation !
Chinglish translations sometimes might miss some important words - here is the spec translated by google from Chinese stating "above" 10us
Also, there are various people reporting issues at using 10 though. Here is something mentioned in the NewPing lib issues queue : https://bitbucket.org/teckel12/arduino-new-ping/issues/41/jsn-sr04t-20-needs-to-have-longer-high
@Timbergetter Isee you are still on 10us delay. I've read somewhere that 10us delay specified for the JSN is too short and causes failed readings in the JSN and I if I recall 15 or 20 us makes it more reliable. @zboblamont already mentioned this, so perhaps you already tried to increase the delay ???
Also, something else someone mentioned elsewhere was that metal casing caused some erratic readings on the JSN and grounding the case to the circuit's gnd helped.
@Timbergetter Can you can post the sketch you are using?
@zboblamont Oh - and its not really winter anymore here - only goes to last month in the screenshots previously shown. Not sure where you're from - but temp inside tanks here range from 0.69 C to 42.7 C - min / max for last year
Here is the last years graph for interest sake !
Here is my first prototype version installed on the rain tank :
@zboblamont I bought this one https://www.hobbytronics.co.za/p/1119/waterproof-ultrasonic-distance-transducer
Looks like its supposed to be the 5V version from those specs.
@Timbergetter I also tried the JSN SR04T sensor and had problems with it. Ended up using the cheap HC-SR04 sensors on my tanks. Have 3 different tank sensors - borehole water tank up the hill, rainwater tank at house and another reverse osmosis filtered water tank. All three going for just over a year now.
Condensation issues / waterproof I resolved by quickly spraying some clear laq spray paint over the sensors. On one tank I also added little standoffs so the sensor is not sealed onto the lid of the tank but rather 5 to 10mm above the lid to let the ambient air pass over and prevent high humidity inside the tank condensing on the sensor.
And then for the code ... I added LM35 temperature sensor and added temp compsensation. Also I do a few readings and average them out.
All-in-all I now get only one or two weird readings on rare occasions - could be a spider !
Here is the last day data of the tank I have up the hill. Its showing pump cycles as well to keep tank topped up - its a weak borehole so i can only pump a little at a time. I have a separate node with relay to turn on/off pump as well as float switch down the hole to detect low water levels in the borehole.
Here is a one week graph of the same tank : temp and distance only shown
Here is one month data
We are just coming out of winter here (in South Africa!) - so temp swings of the air inside the tanks are quite radical between day and night (except the last 2 days its been getting rather warm here !)
Basically - just wanted to let you know/see that the cheap HC-SR04 sensors can do the job - and no more hiking up hills to check tank levels - and also the pumping can be automated too by the controller
@mfalkvidd Thanks - and yes - I did make the assumption that send with ack = true means do a hardware ack. I was unaware that a "software ack" also exists. I read your comment here : https://forum.mysensors.org/topic/3346/discussion-reliable-delivery/17 and what you mention there needs to be made loud and clear in the docs - perhaps some mention in both the message send function and message receive function,
For some reason I am now unable to reproduce the issue on the standard RelayActuator.ino example. It was definitely sending ACK requests when I was testing a few days ago. I have subsequently updated MySensors library and also MyController to their latest Snapshot - so perhaps the issue comes up under one of those scenarios.
The issue around this though is that the example does not report the current status of the relay in the loop. My own sketch was doing so. I guess many people take an example and modify it like I do. Therefore copying the example and adding in the code to send the current relay status periodically means the receive function will not work properly due to the Ack messages received,
I would then suggest adding a note to the receive function of the relay example sketch to say that "if your node sends messages then you need to check for Ack and discard those messages" - or something along those lines. This will help !