General Discussion

@mfalkvidd said in Best way to send nodeDistance and parentNode: @xefil I've never seen anyone reuse a child ID, and I think it would confuse most controllers. Just look at the presentation call: first the sketch would present the child as type X, then the sketch would present the same child as type Y. Will the controller use the first, the second, both or none of the presentations? But you may be right - maybe controllers can handle multiple data types per child id. Well @mfalkvidd maybe it's me that I'm making confusion. AFAYK, in case of HomeAssistant, it has an auto-discovery system which works, even if I don't like the naming convention it uses. BTW, using the above example, subscribing to MQTT server, I can get the values like follow: api doc: MY_MQTT_PUBLISH_TOPIC_PREFIX/FROM-NODE-ID/SENSOR-ID/CMD-TYPE/ACK-FLAG/SUB-TYPE example message published on topic prefix mygateway1-out from node 28, on V_VAR1, which has id 24, becomes: mygateway1-out/28/100/1/0/24 The same way, message published on topic prefix mygateway1-out from node 28, on V_VAR2, which has id 25, becomes: mygateway1-out/28/100/1/0/25 This gives me the ability to subscribe on it and check for changes, like the logs shows me: 2018-12-31 08:37:09 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on mygateway1-out/28/100/1/0/24: b'0.0' 2018-12-31 08:51:09 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on mygateway1-out/28/100/1/0/25: b'1.0' Looking deeper on what the controller recognize it during the presentation, using S_CUSTOM (id: 23) it's reassumed in this part of xml auto-generated: "28": { "protocol_version": "2.3.1", "battery_level": 0, "type": 18, "children": { <code_snipped> "100": { "description": "Internal variables", "id": 100, "values": { "24": "0.0", "25": "1.0" }, "type": 23 } }, "heartbeat": 0, "sketch_name": "node28Studio", "sketch_version": null, "sensor_id": 28 }, So, actually the infos are correctly sent. It's more a matter if the usage of the IDs is correct to avoid further conflicts, if any. That's the reason I'm asking ;-) Thanks, Simon

no, what is it?where can I find the documentation?

By the way, the default baud rate used by MySensors is 115200 so try that if you haven't already.

I just got this to work. It's great! I've updated the first post with a longer guide.

Yes Glædeligt jul :-)

Thanks...it is starting to make a bit more sense of why I may want to use MQTT. Your Vacuum project looks great.

@nickk I changed skins and now I have spyglass search option.

@alexsh1 eh, yeah. Nearly 2 days ;-)

hysteresis https://duckduckgo.com/?q=hysteresis&t=canonical&atb=v79-4&ia=definition

Linux Router https://github.com/axillent/swi_appserver

@thaliquids I would tackle this by finding a controller (here's a few examples of controllers: https://www.mysensors.org/controller) that supports Philips Hue. The controller would then get an event each time a button is pressed on the tap. Then you link a script or other action to that event which switches the tube light on or off. The advantage of using a controller is that the corresponding action can be done on a device totally different from Hue (MySensors, Sonoff, Z-Wave etc.)

@mhmd It's a function of your router's network address translation (NAT). It's the same way your browser can get push notifications (as from this forum). When your Sonoff device communicates with the Chinese server, your router uses a different port number and stores that info. When traffic comes in to your external IP address with that port number the router knows which internal IP address and port to send it to. You can read more about NAT elsewhere. The bottom line is that the Chinese server isn't getting special access to your network and doesn't know your local IP address.

@bjacobse Thanks for the info. I will look into that.

thank you very much! ;)

My advise if you want upgrade and improve your domotics in your house is what i done. Domoticz,serial gateway, rfm69h and rfm69hw instead of nrf24 that i used before and replace all cards. Nrf24 have many range problems for me and the the chinise clone that are unknown quality in each order.all diferents each time i order...

@nagelc I'm working to get the nRF52840 supported by mecrisp-stellaris. If that happens, then it will be faster than uLisp, because then FORTH will automatically compile seamlessly into native machine code rather than running on a VM. Allegedly the performance would then be very close to that of compiled C code. To me that would be like having my cake (interactivity of a REPL) and eating it too (fast execution speed).