Domoticz TEXT sensor triggering

[Sushukka]

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]

@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:
https://www.domoticz.com/forum/viewtopic.php?f=28&t=22801&p=177364#p177364
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.

[Nca78]

Hello,

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.

[Sushukka]

@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...

[gohan]

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

[Sushukka]

@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.

[gohan]

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

[tbowmo]

@sushukka

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..

[monte]

@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:

netcat <gw ip> <port>

python:

#!/usr/bin/python3

import socket
from time import sleep

def gwsend(hostname, port, content):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((hostname, port))
    sleep(1)
    s.sendall(content)
    s.shutdown(socket.SHUT_WR)
    s.close()


string = str.encode("some text")  # Your TEXT message
gwsend("127.0.0.1", 5003, b"2;1;1;1;47;" + string + b"\n")

[Sushukka]

@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.

[tbowmo]

@Sushukka

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 npmjs.com.

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.

[Sushukka]

@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.

[monte]

@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. http://www.steves-internet-guide.com/into-mqtt-python-client/ try to follow those steps, I will try too

[tbowmo]

@Sushukka

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.

[pjr]

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.

[gohan]

That's what I suggest 2 days ago

[kimot]

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:

http://MS_GATEWAY/cmd?node=10&sensor=1&value=80

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.

[gohan]

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.

[monte]

@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.

[kimot]

@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.

[gohan]

But that's out of mysensors protocol and making it an even more complicated workaround

[kimot]

@monte
It can be implemented into existing ethernet gateways, I think.
I experimenting with ESP8266 gateway only, not W5100.

For inspiration look at code line 24 to 56 here:

https://diyprojects.io/driving-gpio-esp8266-web-server-domoticz-tcp-ip-wireless/

[monte]

@kimot I know, that you can make web server on esp8266, but now gateway code works on almost everything that is supported by arduino IDE and has enough memory. If you will make version of gw that only works on esp or raspberry pi it won't be right. For my taste we need affordable microcontroller based on ARM Cortex-M0 (M3, M4) with built-in Ethernet controller and hardware TCP/IP stack. For now there is one chip but it isn't nor affordable nor widely spread, and almost no one knows how to work with it (because no one has it). http://www.wiznet.io/product-item/w7500p/

[Sushukka]

@tbowmo Thanks @tbowmo and everybody! This active community has really saved my day so many times. You rule guys and gals!
Here is a working script:

import paho.mqtt.client as mqttClient
import sys

irCommand = sys.argv[1]
print("Parameter is: " + irCommand)

client = mqttClient.Client("Python")  
client.username_pw_set(username="xxx",password="xxx")
client.connect("nnn.nnn.nnn.nnn", 1883)
client.publish('domoticz/out/HomeNum_IR/0/0/1/0/47', irCommand, retain=False)
# (ESP8266 "gateway" MQTT client -> node=0)

And call it from Domoticz virtual selector switch:

script:///home/pi/domoticz/scripts/python/hnumber_led_mode.py 7

Parameter is the desired mode for led animation. Made a similar on for IR remote commands.

Is there same ~25bit payload limit with MQTT too? I mean those NEC IR commands tend to be 32bit so probably cannot send them directly but need to be hardcoded in the sketch? Also planned to create a universal script for these needs where you could give also node number, child ids etc but then again...I chain myself even tighter to Domoticz shackles and again Domoticz should support this without scripting.

Couple of more questions:

• If you have several ESP8266 MQTT gateways, should one create a different topic for everyone or put them in the same MySensors queue? If so, will the MY_MQTT_CLIENT_ID make the separation?
• I installed nodered-contrib-mysensors and it seems very promising. Definitely going to play around with it. I probably still need some actual controller but Node-red seems to be important part whatever you're gonna do especially when using MQTT queues.
• When using MQTT instead of Ethernet GW, I lose small but very important check: node pinging. I can see from Domoticz log warning messages when some of my ESP8266 Ethernet nodes are down, but when using MQTT there are no warnings, just no data received. I assume this is quite logical because the MQTT node's address in Domoticz is actually broker's (Mosquitto) address + right MQTT topic. However, when sniffing Domoticz MQTT traffic, it seems to send PING messages quite regularly (but don't know if this triggers anything if the ping success or fails...):

// MQTT topic: domoticz/out/HomeNum_IR/#
PING
qos : 0, retain : false, cmd : publish, dup : false, topic : domoticz/out/HomeNum_IR/0/0/3/0/18, messageId : , length : 40

Update: Seems that the Domo has it's own requirements for MQTT queues and for preventing overlapping ESP8266 = GW = Node ID 0 have an option to have also Node ID in the MQTT queue definition. Still would be nice to be able to define the MQTT queue names freely in Domo...

Also my bad: MySensors payload size is 25 bytes, not bits... This seems to be because of NFR24L01 limitations. However, it would be nice to see an extended payload size for passing eg. longer text information with more advanced microcontrollers like ESP8266 in the future releases. Minor need though.

[tbowmo]

@kimot
So MQTT is not a common protocol? Or serial? What would the benefit be of a http request, over any of the other transport options, when the controller doesn't transmit when changed?

In my opinion then http requests aren't that usable as a transport in a home automation setup. MQTT is much better for this, if you really want to go over tcp/ip.

[Sushukka]

And update here about V_TEXT and OpenHAB: Yes it works like it should. When I update the V_TEXT sensor in OpenHAB, it will send the update without any extra scripts or hacks to the MySensors node.

However, after spending several days and nights setting up OpenHAB I have to say that it is far from being ready. MySensors seems not to be qualified yet in the list of "downloadable ready" bindings in PaperUI. Had several errors with MQTT nodes. It is customizable yes, but requires way too much time to set up and maintain. It seems to be more like an architectural masterpiece than easy-to-use home controller.

You can define nearly everything in PaperUI or HABmin like me (a hell of mouse clicking and scrolling) or define everything in multiple configuration files. When you finally have all the nodes and sensors defined (bindings, things, items), you have to build your own gui to see them in usable format. You can either use HabPanel for dashboards or configuration files for sitemaps. Dashboards, which has the best outlook imo, seems to have a problem of working with different devices. I tried to avoid the manual sitemap building by installing Imperihome binding. Connection ok, but alas, you have to manually tag every damn item you have to show them in Imperihome. With all manual configurations you actually need to define quite much of information and they are nicely connected making bigger future changes complicated. Having now around 100 sensors, all this stuff really takes time. Moreover it seemed that the reliability at least with MySensors Ethernet Gateways (one main for NFR24L01 nodes and several ESP8266s) was not in par with Domoticz. Startup problems, rebooting, lost nodes etc...And this was the last drop --> changed back to Domoticz.

Have to say that after a couple of years OpenHAB could maybe be the number one open source home automation controller, but it requires lots of more work for getting there. Now it's too much of engineering and configuration porn vs. the real benefits it gives. Also I'm little bit afraid that the they are getting lost to this super elegancy by trying to be everything and pleasing everybody. PaperUI, HABmin, HomeBuilder, HabPanel, Basic UI, Classic UI, some third party UIs, configuration files... The concept is nice, but as with any product, you need to focus somewhere or otherwise you are just semicore in all areas. Domoticz has its problems, but at least it is reliable and allows putting the most of the available tinkering time to the actual node building than tuning the controller.

[monte]

@sushukka why don't you use configs? It's not too hard to write them and you don't need to find options in incomplete gui. But I agree that their approach doesn't suit well for tinkering and building system step by step adding few devices every couple of days, or changing the layout. I guess it has more use for complete systems that doesn't require adding new things more than once in few months.
I have to say that I like Domoticz' way of setting things up more, but the fact that it's almost not developing and amount of lag and unpolished corners here and there...It doesn't feel robust enough to suggest it to someone else than myself or people like ones on this forum.

[Sushukka]

@monte True that. Thing is that people like to use the guis instead of configuration files. That's probably the reason why OpenHAB "fastly" evolves in that direction.

For all the not-so-technical home automation builders I would myself suggest Domoticz as the choise for open source controller. OpenHAB maybe for the ones who buys ready-made stuff from Ikea, zWave etc and just want to control the stuff from one place. But still I'm pretty sure that many of those are not really interested or have required knowledge to start tinkering with OpenHAB. For MySensors users, as you said, it creates lots of additional work for little extra over Domoticz. Domo has this stupid V_TEXT sensor limitation and some people like that the default graphing stuff is limited. However, OpenHAB has nothing without setting up persistence services and their separate databases and definitions...and you can have the praised Influx-Grafana integration also for Domo. My personal opinion is that the normal Domo gui is still pretty useful plus you can have Imperihome, Dashticz type of connections or build your own with Rest API. With OpenHAB you don't have anything usable without manually building it first. I'm myself using Imperihome which basically gives little to complain about gui usability and visual aesthetics. With Domo you install MyDomoAtHome which has all the mappings done so that you can just start playing around with your Imperihome gui. With OpenHAB...
https://github.com/openhab/openhab2-addons/tree/master/addons/io/org.openhab.io.imperihome
The tagging part is not a small work to do...and this pretty much underlines the problem with OpenHAB. You can tune everything, but basically spend huge amount of time on doing that...or even getting things to work on basic level. The OpenHAB community seems to be active, but it has to, as there seems to be lots of problems too.

But not bashing OpenHAB more: I want to like it, but it's just making liking it too hard for now. However, it has Eclipse foundation backing it up and has started evolving to the right direction out of the pure configuration file based setup/tuning. After year or two I believe it's much more user-friendly and more widely used. If not and Domo won't be developed anymore there is always the middleware/MQTT/NodeRed/cloud options to go...

[monte]

@sushukka I'm using Domoticz myself at home, but have chosen OpenHAB as a platform for my friend's home automation project I'm working on. We are using some KNX modules and for now only openhab has native support for it (among platforms that are kept developing). Another big advantage of openhab is number of different bindings for different hardware and community that is willing to write the new ones. On the other hand developers of Domoticz either ignore your suggestions or tell you to implement them yourself. Can't see a bright future with such an attitude.

[Sushukka]

@monte I fully agree with this. I have tried to get some explanation to this V_TEXT problem through multiple channels and no one is really answering anything. Either the developers have dumped the whole project or are just nasty dwarfs in a cave. GitHub shows some activity but the project seems to lay very heavily on "gizmocuz" shoulders who probably has a nasty attitude but has also answered to this V_TEXT question 7/2017 not easily implemented -> Best to help with development...so it seems that they are lacking hands...but in other hand, if the attitude is bad there aren't probably many willing to come to help.

So...same here, I'll continue using Domoticz, but actively seeking a better alternative for it and trying to build as little as possible Domoticz specific stuff.

[gohan]

I have to say that domoticz is pushing out one or 2 updates for beta on a weekly basis, so something is moving. But yes, it seems there aren't many people actively developing it.

[Sushukka]

Here is the latest update:
https://github.com/domoticz/domoticz/issues/2380
At least got some response...do it yourself.
Darn sad: a good, reliable and widely-used product, but the developers are just pricks or don't give shit. With better attitude this could be so much more and most likely there would be lots of more contributors helping with them.

[gohan]

Agreed, that is bad but on the other side consider it is a feature not used much actually.

[Nca78]

@gohan said in Domoticz TEXT sensor triggering:

Agreed, that is bad but on the other side consider it is a feature not used much actually.

Well I don't use it at the moment, but only because it's a PITA with Domoticz...

[GertSanders]

@gohan I would love to have that feature so I can send updates to a LCD equipped sensor, without the "switch" hack.
Polling is really inefficient, one should be able to send V_TEXT just like V_STATUS.

[gohan]

Don't get me wrong, I understand, I was just considering that it a feature not needed by many people and it is still on the feature request list

[alowhum]

I built a partial solution for this in the Aurora theme for Domoticz. With it you can just change the vText variable value in the interface.

• Install Aurora
• Go to Utility tab
• click on the text value. It will change into an edit field. Click outside of it when you're done.

The node still needs to poll Domoticz periodically to request the new value. But at least you can change the value easily this way.

[Sushukka]

YEEEEEEESSSSHHH!!! This is now implemented in Domoticz!
https://github.com/domoticz/domoticz/issues/2380

You can change the V_TEXT sensor value from Domoticz via JSON, Scripts and Blocky and the update will be sent directly to the node without any hacks!!! This is big update; you can pass lots of information, parameters etc directly to the nodes without extra steps. And @alowhum you don't need that poll anymore in the sketch. LCD screen updates, speech-to-text commands...now we just need bigger payload size for MySensors...

[alexsh1]

@gertsanders said in Domoticz TEXT sensor triggering:

@gohan I would love to have that feature so I can send updates to a LCD equipped sensor, without the "switch" hack.
Polling is really inefficient, one should be able to send V_TEXT just like V_STATUS.

you ca do it now with the latest update

[alowhum]

What other things are bi-directional with Domoticz?

Fo example I'm looking to receive a setpoint value from Domoticz for a node that is an oven controller. Dresenting a s_hvac and then setting a new temperature in Domoticz, does that automatically get sent back to a node? Or is there a setpoint something?

[tbowmo]

@alowhum

If I remember right, then domoticz sends the new temperature to the device, but only updates the gui when it receives a value from the node. So your node sketch have to reply the set command from your controller, with another set command, which sends the value back to your controller.

[gohan]

@alowhum those kind of values should be sent automatically to the node if they are changed in domoticz

[kimot]

@alowhum

bool MySensorsBase::WriteToHardware(const char *pdata, const unsigned char length)
{
	const tRBUF *pCmd = reinterpret_cast<const tRBUF *>(pdata);
	unsigned char packettype = pCmd->ICMND.packettype;
	unsigned char subtype = pCmd->ICMND.subtype;

	if (packettype == pTypeLighting2)
	{
		//Light command

		int node_id = pCmd->LIGHTING2.id4;
		int child_sensor_id = pCmd->LIGHTING2.unitcode;

		if (_tMySensorNode *pNode = FindNode(node_id))
		{
			_tMySensorChild *pChild = pNode->FindChild(child_sensor_id);
			if (!pChild)
			{
				_log.Log(LOG_ERROR, "MySensors: Light command received for unknown node_id: %d, child_id: %d", node_id, child_sensor_id);
				return false;
			}

			int light_command = pCmd->LIGHTING2.cmnd;
			if ((pCmd->LIGHTING2.cmnd == light2_sSetLevel) && (pCmd->LIGHTING2.level == 0))
			{
				light_command = light2_sOff;
			}
			else if ((pCmd->LIGHTING2.cmnd == light2_sSetLevel) && (pCmd->LIGHTING2.level == 255))
			{
				light_command = light2_sOn;
			}

			if ((light_command == light2_sOn) || (light_command == light2_sOff))
			{
				std::string lState = (light_command == light2_sOn) ? "1" : "0";
				if (pChild->presType == S_LOCK)
				{
					//Door lock/contact
					return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_LOCK_STATUS, lState, pChild->useAck, pChild->ackTimeout);
				}
				else if (pChild->presType == S_SCENE_CONTROLLER)
				{
					//Scene Controller
					return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, (light_command == light2_sOn) ? V_SCENE_ON : V_SCENE_OFF, lState, pChild->useAck, pChild->ackTimeout);
				}
				else
				{
					//normal
					return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_STATUS, lState, pChild->useAck, pChild->ackTimeout);
				}
			}
			else if (light_command == light2_sSetLevel)
			{
				float fvalue = (100.0f / 14.0f)*float(pCmd->LIGHTING2.level);
				if (fvalue > 100.0f)
					fvalue = 100.0f; //99 is fully on
				int svalue = round(fvalue);

				std::stringstream sstr;
				sstr << svalue;
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_PERCENTAGE, sstr.str(), pChild->useAck, pChild->ackTimeout);
			}
		}
		else {
			_log.Log(LOG_ERROR, "MySensors: Light command received for unknown node_id: %d", node_id);
			return false;
		}
	}
	else if (packettype == pTypeLimitlessLights)
	{
		//RGW/RGBW command
		_tLimitlessLights *pLed = (_tLimitlessLights *)pdata;
		//unsigned char ID1 = (unsigned char)((pLed->id & 0xFF000000) >> 24);
		//unsigned char ID2 = (unsigned char)((pLed->id & 0x00FF0000) >> 16);
		unsigned char ID3 = (unsigned char)((pLed->id & 0x0000FF00) >> 8);
		unsigned char ID4 = (unsigned char)pLed->id & 0x000000FF;

		int node_id = (ID3 << 8) | ID4;
		int child_sensor_id = pLed->dunit;

		if (_tMySensorNode *pNode = FindNode(node_id))
		{
			_tMySensorChild *pChild = pNode->FindChild(child_sensor_id);
			if (!pChild)
			{
				_log.Log(LOG_ERROR, "MySensors: Light command received for unknown node_id: %d, child_id: %d", node_id, child_sensor_id);
				return false;
			}

			bool bIsRGBW = (pNode->FindChildWithPresentationType(child_sensor_id, S_RGBW_LIGHT) != NULL);
			if (pLed->command == Limitless_SetRGBColour)
			{
				int red, green, blue;

				float cHue = (360.0f / 255.0f)*float(pLed->value);//hue given was in range of 0-255
				int Brightness = 100;
				int dMax = round((255.0f / 100.0f)*float(Brightness));
				hue2rgb(cHue, red, green, blue, dMax);
				std::stringstream sstr;
				sstr << std::setw(2) << std::uppercase << std::hex << std::setfill('0') << std::hex << red
					<< std::setw(2) << std::uppercase << std::hex << std::setfill('0') << std::hex << green
					<< std::setw(2) << std::uppercase << std::hex << std::setfill('0') << std::hex << blue;
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, (bIsRGBW == true) ? V_RGBW : V_RGB, sstr.str(), pChild->useAck, pChild->ackTimeout);
			}
			else if (pLed->command == Limitless_SetColorToWhite)
			{
				std::stringstream sstr;
				int Brightness = 100;
				int wWhite = round((255.0f / 100.0f)*float(Brightness));
				if (!bIsRGBW)
				{
					sstr << std::setw(2) << std::uppercase << std::hex << std::setfill('0') << std::hex << wWhite
						<< std::setw(2) << std::uppercase << std::hex << std::setfill('0') << std::hex << wWhite
						<< std::setw(2) << std::uppercase << std::hex << std::setfill('0') << std::hex << wWhite;
				}
				else
				{
					sstr << "#000000"
						<< std::setw(2) << std::uppercase << std::hex << std::setfill('0') << std::hex << wWhite;
				}
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, (bIsRGBW == true) ? V_RGBW : V_RGB, sstr.str(), pChild->useAck, pChild->ackTimeout);
			}
			else if (pLed->command == Limitless_SetBrightnessLevel)
			{
				float fvalue = pLed->value;
				int svalue = round(fvalue);
				if (svalue > 100)
					svalue = 100;
				std::stringstream sstr;
				sstr << svalue;
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_PERCENTAGE, sstr.str(), pChild->useAck, pChild->ackTimeout);
			}
			else if ((pLed->command == Limitless_LedOff) || (pLed->command == Limitless_LedOn))
			{
				std::string lState = (pLed->command == Limitless_LedOn) ? "1" : "0";
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_STATUS, lState, pChild->useAck, pChild->ackTimeout);
			}
		}
		else
		{
			_log.Log(LOG_ERROR, "MySensors: Light command received for unknown node_id: %d", node_id);
			return false;
		}
	}
	else if (packettype == pTypeBlinds)
	{
		//Blinds/Window command
		int node_id = pCmd->BLINDS1.id3;
		int child_sensor_id = pCmd->BLINDS1.unitcode;

		if (_tMySensorNode *pNode = FindNode(node_id))
		{
			_tMySensorChild *pChild = pNode->FindChild(child_sensor_id);
			if (!pChild)
			{
				_log.Log(LOG_ERROR, "MySensors: Light command received for unknown node_id: %d, child_id: %d", node_id, child_sensor_id);
				return false;
			}

			if (pCmd->BLINDS1.cmnd == blinds_sOpen)
			{
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_UP, "", pChild->useAck, pChild->ackTimeout);
			}
			else if (pCmd->BLINDS1.cmnd == blinds_sClose)
			{
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_DOWN, "", pChild->useAck, pChild->ackTimeout);
			}
			else if (pCmd->BLINDS1.cmnd == blinds_sStop)
			{
				return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, V_STOP, "", pChild->useAck, pChild->ackTimeout);
			}
		}
		else {
			_log.Log(LOG_ERROR, "MySensors: Blinds/Window command received for unknown node_id: %d", node_id);
			return false;
		}
	}
	else if ((packettype == pTypeThermostat) && (subtype == sTypeThermSetpoint))
	{
		//Set Point
		const _tThermostat *pMeter = reinterpret_cast<const _tThermostat *>(pCmd);

		int node_id = pMeter->id2;
		int child_sensor_id = pMeter->id3;
		_eSetType vtype_id = (_eSetType)pMeter->id4;

		if (_tMySensorNode *pNode = FindNode(node_id))
		{
			_tMySensorChild *pChild = pNode->FindChild(child_sensor_id);
			if (!pChild)
			{
				_log.Log(LOG_ERROR, "MySensors: Light command received for unknown node_id: %d, child_id: %d", node_id, child_sensor_id);
				return false;
			}

			char szTmp[10];
			sprintf(szTmp, "%.1f", pMeter->temp);
			return SendNodeSetCommand(node_id, child_sensor_id, MT_Set, vtype_id, szTmp, pChild->useAck, pChild->ackTimeout);
		}
		else {
			_log.Log(LOG_ERROR, "MySensors: Blinds/Window command received for unknown node_id: %d", node_id);
			return false;
		}
	}
	else if (packettype == pTypeGeneralSwitch)
	{
		//Used to store IR codes
		const _tGeneralSwitch *pSwitch= reinterpret_cast<const _tGeneralSwitch *>(pCmd);

		int node_id = pSwitch->unitcode;
		unsigned int ir_code = pSwitch->id;

		if (_tMySensorNode *pNode = FindNode(node_id))
		{
			_tMySensorChild* pChild = pNode->FindChildByValueType(V_IR_RECEIVE);
			if (pChild)
			{
				std::stringstream sstr;
				sstr << ir_code;
				return SendNodeSetCommand(node_id, pChild->childID, MT_Set, V_IR_SEND, sstr.str(), pChild->useAck, pChild->ackTimeout);
			}
		}
		else {
			_log.Log(LOG_ERROR, "MySensors: Blinds/Window command received for unknown node_id: %d", node_id);
			return false;
		}
	}
	else
	{
		_log.Log(LOG_ERROR, "MySensors: Unknown action received");
		return false;
	}
	return true;
}```

[alowhum]

@kimot : Thanks! If I'm reading that domoticz code correctly:

• All kinds of switches, including percentage and V_IR_RECEIVE
• "sTypeThermSetpoint"
• Hmm, I don't see the V_text update in that code

@tbowmo : I had discovered that by experimenting, good to see it confirmed by you too.

[kimot]

@alowhum
There are some changes in V_TEXT type in latest builds.
Read this:
https://forum.mysensors.org/topic/9340/domoticz-v_text-sensor-now-bidirectional