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

You can change the V_TEXT sensor value in 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 work-arounds. LCD screen updates, speech-to-text commands, parameter/code driven nodes...now we just need bigger payload size for MySensors...

Edit: Just remember when updating that you may need to change your old sketches + tricks and hacks because you now get the V_TEXT update twice if you have the old hacks active.

sushukka created this issue in domoticz/domoticz

closed MySensors V_TEXT variable two-way update #2380

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

sushukka created this issue in domoticz/domoticz

closed MySensors V_TEXT variable two-way update #2380

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

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.

sushukka created this issue in domoticz/domoticz

closed MySensors V_TEXT variable two-way update #2380

@mfalkvidd Hehheh, now it works. I commented out the ADC_MODE line from MyHwESP8266.cpp. It seems that in my version (newest MySensors core available in Arduino IDE) the ADC_MODE line is out of the #ifdef MYDEBUG-clause. It's just a free floating line in the root of the application logic.

int8_t hwSleep(uint8_t interrupt1, uint8_t mode1, uint8_t interrupt2, uint8_t mode2, unsigned long ms) {
	// TODO: Not supported!
	(void)interrupt1;
	(void)mode1;
	(void)interrupt2;
	(void)mode2;
	(void)ms;
	return -2;
}

// ADC_MODE(ADC_VCC);

uint16_t hwCPUVoltage() {
	// in mV
	return ESP.getVcc();
}

uint16_t hwCPUFrequency() {
	// in 1/10Mhz
	return ESP.getCpuFreqMHz()*10;
}

uint16_t hwFreeMem() {
	return ESP.getFreeHeap();
}

Now it works perfectly. Thank you a lot for your patience mfalkvidd! There are some calibration issues when having Wifi and all other stuff up and running. Basically this is related to the statistics functions but that's no problem, I just switched back to the old algorithm and now measurement works within 10W tolerance using 5V input to sensor. Still even with MYDEBUG variable on, I very much wonder why MySensors change the only ESP8266 analog pin for internal voltage measurement.

Update: Managed to get my NFR24 radios work with Sensebender micro with greatly oversized 100uF normal electrolytic capacitor. Been in my freezer (appr. -20C) now for three days and still works fine. 2xAA batteries powering the node. Not sure where the problem is, maybe just the capacitor size because of diminishing capacitance curve in freezing temperatures. Have still some spare Nanos and Pros to spend, but gradually moving to ESP8266 based sensor network. They have proven to be very reliable even under -20 degrees celsius.

I have only one line going through ACS712 and then its splitted to multiple outlets with extension cord. First I though that my 20A ACS712 is actually only 5A one, but same problem happes with the second ACS712 20A. Also even 5A should be able to measure this load as Prusa's maximum intake is around 180W.
Maybe it has something to do with the power factor, dunno. Now I have anyway managed to pinpoint the problem to 3D printers. When plugging only Arduino+ACS712+Prusa MK2 to the wall, ACS712 shows around 690W loads when the Prusa's maximum is about 180W as mentioned above. My old faithful hair dryer power consumption is measured correctly (430W, 820W, 1400W).

@Yveaux said in ACS712 strange values when measuring 3D printer power consumption:

void setup() {
Serial.begin(115200);
}

void loop() {
Serial.println( analogRead(A0) );
}

Cool, haven't thought you could use plotter like this. Hair dryer gave pretty sin/cos like load, Kossel 3D printer with a normal computer supply is quite close but Prusa's load was pretty spiky. It looked like:

                /|
               / |
              |   \
      /------/    |
----/             \----

Which probably underlines pretty well your point. Question is that is there anyway to tackle this when using emonlib?

@Yveaux ASCII art + SID music ftw. I played around with the sampling time (changed from 1480 to 3000/6000):

double Irms = emon1.calcIrms(6000)

Now the values are pretty close together. Still had to manually do the zero load subtraction (around 30W) but after that ACS712 shows surprisingly accurate values even for low 10/20W loads. Now it seems that when Prusa is heating up I get constantly around 100W higher values than I should. But when I turn the Kossel or hair dryer on = adding load to the same line, the Prusa crap seems to fitted in (or filled in) so that the total load seems to be accurate. My "reference" power meter could be off for reactive loads, but not this much and moreover Prusa's power supply is around 200W and I get 300W readings from ACS712.

Anyway, I think I'll take the "so be it" step now and just have to live with the fact that Prusa will skew my power readings a bit. Usually there will be some other load in the same line so it should be partly corrected by that. Your help @Yveaux was pretty useful and I thank you for that. Also I usually have trusted to some homemade power calculation algorithms because OpenEnergyMonitor is so heavily based on CT3 but as I now saw how much better accuracy its algorithms give I'm going to switch in to that in future projects.

Weather station has been working lately pretty well. Only sometimes there can be an hour connection break or so. Therefore PA LNA may be just enough. So I'll build an outside repeater based on that and if it doesn't help I have now couple of other paths (double antenna, second ethernet gateway) to go. Thanks again fellow forum members, the community here is one of the most active in this area I have seen!

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

You can change the V_TEXT sensor value in 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 work-arounds. LCD screen updates, speech-to-text commands, parameter/code driven nodes...now we just need bigger payload size for MySensors...

Edit: Just remember when updating that you may need to change your old sketches + tricks and hacks because you now get the V_TEXT update twice if you have the old hacks active.

sushukka created this issue in domoticz/domoticz

closed MySensors V_TEXT variable two-way update #2380

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

sushukka created this issue in domoticz/domoticz

closed MySensors V_TEXT variable two-way update #2380

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.

sushukka created this issue in domoticz/domoticz

closed MySensors V_TEXT variable two-way update #2380

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

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

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.

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

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

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