Domoticz TEXT sensor triggering

[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... :D

[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