Domoticz TEXT sensor triggering

  • Hello,
    This is already very well discussed topic, but I would like to broaden the scope a little bit without stealing anyones thread. So here it goes.
    There has been now several cases in my microcontroller journey with MySensors and Domoticz where I need to pass some command or code to some node for further processing. For example I want to have different lighting or user modes in some node. I create a dummy sensor on Domoticz and selector swith on that. After that I define a V_TEXT sensor on the node. Now I can simply update the TEXT sensor via the selector swith (Json commands) and the TEXT sensor variable will be updated. However, the information will not be passed to the node without explicitly requesting it from the node.

    MySensors/Domo support lots of ready made devices like RGB, switches, dimmers etc, but sometimes that's not just enough. The best way to pass information via controller is now by using V_TEXT/S_INFO sensor type, but it has a major downfall that Domoticz wont trigger anything when one of this type of sensors is updated. This forces MySensors users to do all kind of gimmicks with receive command triggering switches, dimmer hacking etc. All of which makes Domoticz ugly and kind a hacked.

    So what are the alternatives? I don't know, suggestions fellow MySenors users? The dummiest way is to make a poll requesting the TEXT info in regular manner. Works, but too inefficient. Other way is the dimmer type of hacking on Domo. I haven't used MQTT yet, could it be useful here? All the sensors and nodes are anyway MySensors ones so I assume that the Domo trigger problem persist. How about creating some generic lua script on Domo sending the information when it gets changed? Is it even possible to access this Domo/MySensors communication level ?

  • @sushukka Strangely quiet here. πŸ™‚ This seems to be kind a common problem as there are many workarounds built because of this. However, I haven't seen no reasoning anywhere why the TEXT sensor update in Domoticz will not trigger any event to send the update to the node.
    I opened/continued a thread also on Domoticz forum:
    Some LUA scripting maybe needed, but not sure yet. Still I see this a very crucial shortcoming as there are lots of cases where you need to pass parameters/commands etc. short information between Domo and MySensors nodes.

  • Hardware Contributor


    I don't think you will get response about the "why" questions on Domoticz here πŸ™‚
    It's great for setting up easily your home automation setup, but there are some strange design choices/behaviours that quickly add up to make it some kind of a lua scripts nightmare. But that's another discussion πŸ˜„
    Sorry not to have a solution to give you, I'm still using Domoticz but as soon as I'll find time I'll switch to something else.

  • @nca78 Thanks for the feedback. I have had similar feeling towards Domoticz for some while. What controller would you suggest? Have been watching OpenHab more closely now, but the conversion work required... πŸ˜–

  • Mod

    You could use a binary switch on the node that you can trigger to have the node request the text value you want. Not the ideal solution but it would just require a minor change. Otherwise you would have to start bothering the domoticz developers 😁

  • @gohan True...I'm just trying to find a way to avoid that darned dummy switch here and there mess. Have been playing with them too much lately. Domoticz developers seems to be also pretty slow to react to any suggestions. Ok, I don't pay to them, but HA and OpenHAB feels a bit more active nevertheless. Probably need to go the dummy hack path again, sigh. Probably have to change the controller soon as every this type of hack makes the conversion even harder in future.

  • Mod

    Life sucks, I know 😁

    I see your point, my suggestion was merely a workaround to the node running but if you foresee domoticz limitations a problem for the future, maybe it could be worth moving to another controller now that you don't have too many nodes around

  • Admin


    you could try the different controllers out, checking their capabilities.

    For my part, I switched off domoticz more than one month ago, after I had converted my limited automation scripts over to node-red. Today I deleted the domoticz docker container as well.. No need for it to take up disk space πŸ™‚ I have kept the configuration volume for domoticz, so I can spin up a new instance of it in minutes..

  • @sushukka You can use netcat or socket connection from python script to send message directly to mysensors GW, omitting domoticz. Then you can link this script to your dummy switch in domoticz. It works.


    netcat <gw ip> <port>


    import socket
    from time import sleep
    def gwsend(hostname, port, content):
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((hostname, port))
    string = str.encode("some text")  # Your TEXT message
    gwsend("", 5003, b"2;1;1;1;47;" + string + b"\n")

  • @gohan said in Domoticz TEXT sensor triggering:

    Life sucks, I know 😁

    I see your point, my suggestion was merely a workaround to the node running but if you foresee domoticz limitations a problem for the future, maybe it could be worth moving to another controller now that you don't have too many nodes around

    Around a hundred sensors now and growing...not very excited of the conversion work... πŸ˜• However, started some planning already and now MySensors GW is converted from serial to W5100/MQTT and Node-red has been installed. Have had plans to test it for a some while, but now really started playing with it. Seems that you can do all kind of nice middle-level stuff with it. πŸ’ͺ

    Plan now is to test some other controller via MQTT but only by subscribing to the MySensors queue.

    Also interesting to hear that people have switched totally to Nodered ( @tbowmo do you still have some controller or just Node-red gui/dashboard). Is there some ready-made interpreters for MySensors messages or need one define them all manually?

    And @monte, I definitely think your solution is the coolest one...but I know that if I take this alluring path, I'll end even deeper with the domo hacking I want to get rid off. 😁

  • Admin


    I have switched completely to nodered, my automation is done in flows (you can check it out on github).

    There is a set of mysensors nodes for nodered, that decode / encode MySensors serial protocol, and MySensors MQTT topics, and also enables you to create dummy mysensors nodes, and inject that data into your streams, they can be found on the forum here, or on

    What I do not have, is the ability to hand out new node-id's (yet) I am investigating how to do that in a sensible way, so that data is persisted across restarts / re-deploys of node-red.

  • @monte I need to move to a next project so before conversion to Node-red and/or OpenHAB, how would you use netcat type of injection with MQTT? I mean now I have MySensors in W5100/MQTT mode and I want to send an update to my V_TEXT sensor via MQTT. Easiest way to do this with Domoticz would be by triggering some script. Sending an MQTT update via Python is probably easy (dunno, haven't done yet), but I have no idea how to form the message so that it would be in correct MySensors format...My node id is 31 and the text sensor child is 1:

    #define MY_NODE_ID     31
    #define LED_MODE_ID     1 
    MyMessage msgLedMode(LED_MODE_ID, V_TEXT);

    The payload is some number between -1 to 56. Really appreciate your help. 😌

  • @sushukka I have limited knowledge of mqtt, I'm not using it in my setup, with ncat you can only talk directly to tcp/udp socket and mqtt is built above it. But there is mqtt library for python, and guides for using it. try to follow those steps, I will try too πŸ™‚

  • Admin


    mqtt publish example in python

    import paho.mqtt.publish as publish
    payload = 'Hey there'
    publish.single('mys-out/1/1/1/0/47', payload, hostname=<mqtthost>, port=<mqttport, retain=False)

    'mys-out/99/1/1/0/47' is the MQTT topic, and is decoded as follows:
    99: Node ID
    1: ChildId
    1: command (Set in this case)
    0: ACK (None in this case)
    47: V_TYPE (V_TEXT in this case)

    Above pretty much follows the MySensors serial protocol, as found here, only difference is that sensor payload, and sensor id / msg type etc. is split into two parameters in MQTT (as in payload and topic), and doesn't come in as a single string.

  • How about presenting additional S_BINARY/V_STATUS in your node. In domoticz when text changes set this to ON/OFF. From there you now its time to request text from domoticz.

  • Mod

    That's what I suggest 2 days ago 😁

  • I think, all this is not Domoticz problem, but mysensors problem.
    Mysensors gateways has not got any universal input interface.
    This is, why I am not using pure mysensors solution.
    Imagine, that your gateway understood something like this:


    And translate it to mysensors network message, which sends value 80 to sensor number 1 of node number 10.
    Then you can send into your node everything not only from Domoticz, but from simply Android application and etc.
    With ESP8266 gateway you need only "ESP8266HTTPClient" library to parse this http call for example.

  • Mod

    If the node requests the TEXT to domoticz, it gets the value, so domoticz can actually handle it, the problem is that it does not send the TEXT value if something changes the variable but only if the node requests it.

  • @kimot then it would be a controller itself, not a gateway. You need gateway anyway (sick rhyme), or you would need to use only powerful enough hardware to implement web server to handle requests as you suggest. But it wouldn't be backward compatible with arduino gateways, thus it's not the way for now, maybe in the future we will come to it.

  • @gohan
    But this is what I wrote.
    If anything changes in Domoticz ( not only TEXT value, but anything ), Domoticz sends http call into gateway and thats all.
    For example - you changed setpoint in Domoticz and it seds it immediately into mysensors gateway.