Domoticz plugin

[kgschlosser]

...and EG just keeps on handling all this, yeah, that is impressive, one of many reasons we keep on improving!

that it does.... without issue

one nifty little feature i added to it, the ability to run macros in their own thread (one thread per event as not to have a clash) it runs crazy fast too.

[krambriw]

Maybe a bit OT but we could imagine it is related since also performance is discussed in this topic, use of threading is key and one major advantage with Python. Compare this with popular javascript that runs single threaded...makes me wonder why it is soooo popular. I have used threading a lot in my plugins over the years, this has always been possible, a good example where this is fully explored is my ClimateDataCalculation plugin.

Now that you have added this to macro executions is definitely a very important improvement in many ways.

[kgschlosser]

I started playing around with processes. which is the only way to get python to run multi core. that's why if you have a quad core processor EG will never take up more then 25% because that is 100 % of a single core (unless you change the affinity). so in order to go over that you would need to spawn processes. which has a significant amount of overhead. and from what I have seen it actually makes EG slower.

On an OT note... I did a build of Domoticz it's actually very easy. This has fixed a couple of bugs. but it has also improved the response time of the UI.

here is the exact process to build it...

Install Visual Studio Community Edition. make sure you add the C++ bits to it and also add the standard library. the total install should be about 5 gig.
download the source from https://github.com/domoticz/domoticz
unzip the source.
download the windows libraries from from https://github.com/domoticz/win32-libraries
unpack the libraries into the msbuild folder
in the msbuild folder locate the file domoticz.vcxproj, right click it and click on open with. and select Visual Studio 2017
once it has loaded. at the top click the build drop down menu click on configuration manager. at the top of the manager under "Active solution configuration" change it to Release and then close the manager
click on the build menu again and click on rebuild solution.

You will see a whole lot of warnings. do not worry about those.

If you have Domoticz running as a service you will need to stop the service.
I have not tried to fix this issue. if you have it installed as a service it will no longer run that way. you are going to have to run it like an application.
go and backup your installed Domoticz then delete all the files and folders in the install directory

folders that will need to be moved form the source to the Install directory.
Config
plugins
scripts
www

files that will need to be copied from the backup folder (some of these you may have and some you may not.)

domocookie.txt
domoticz.db
libcurl.dll
nssm
OpenZwave.dll
ozwcp.poll.XXXXXX.xml
server_cert.pem

now back to the msbuild folder. and under release you will see the main domoticz executable. you will need to copy this as well
if you have any plugins/custom floorplans or anything else you will have to copy those as well from the backup folder.

[Foune]

I've been working some hours for integrating in eg a clever python/lua mechanism coded by someone else : one one side, a lua script that keeps alive, and when a device data changes in domoticz it triggers a "tcp socket data transfer" to a python "tcp listener" that updates a "mirrored" data set. I could make the python side code work in eg (I had to backport it from python 3 to 2.6), but I couldn't make the lua side work because it is very hard to get the right LUA version work with all necessary libraries under windows. So it is a fail for now. I can share my python side version, some functions are working, for instance one that checks all old devices in domoticz (those that havn't been updated since x days) and deleted them.

The original code is here. This mechanism would garantee instant fresh domoticz device data within the eg context without having to deal with MQTT. Because I often need to use the device properties out of their MQTT events.

As a workaround, I just made a script to schedule Sunset and Sunrise events based on the Domoticz values. This is a simple proof of concept I did to retrieve some Domoticz values that MQTT won't send.

Code: Select all

import json
import urllib
import datetime as dt

DOMOTICZ_URL = 'http://192.168.1.18:8080/json.htm?type=command&param=getSunRiseSet'

result = json.load(urllib.urlopen(DOMOTICZ_URL))

print("Sunset at " + result['Sunset'])
print("Sunrise at " + result['Sunrise'])

sunset = result['Sunset'].split(':')
sunrise = result['Sunrise'].split(':')

now = dt.datetime.now()
sunsetTime = dt.datetime(now.year, now.month, now.day,int(sunset[0]),int(sunset[1]),00)
sunriseTime = dt.datetime(now.year, now.month, now.day,int(sunrise[0]),int(sunrise[1]),00)

sunsetCountdown = (sunsetTime - now).seconds
sunriseCountdown = (sunriseTime - now).seconds

print("Sunset countdown : " + str(sunsetCountdown) + "s")
print("Sunrise countdown : " + str(sunriseCountdown) + "s")

eg.scheduler.AddTask(sunsetCountdown,eg.TriggerEvent,"Set", "", "Sun")
eg.scheduler.AddTask(sunriseCountdown,eg.TriggerEvent,"Rise", "", "Sun")

[kgschlosser]

with Domoticz you can access almost anything from the web API they have. the thing that I don't like is you have to set polling loops. to retrieve the data. and each time you do that the web server in domoticz has to process the information and so on an so forth. it's a HUGE waste. and their python interpreter is crippled by design. and you can't access the domoticz API from the interpreter other then to create new devices. you do not have the ability to access already made ones. and they have no means to grab states of devices and easily shoot them over to another running program whether it be through a socket or a named pipe. the thing with domoticz in order to do anything with it you have to know C++ or C which ever it is. Lua, python and I am sure there is probably some xml and java tossed in there as well. and trying to get all of those things to talk to one another is a bloody mess I am sure. But Domoticz is slow plain and simple. 2 lights in it and I have the polling time set to 10 seconds and maybe after a minute it might update the status of the light if i turn it on manually. and even that is a crap shoot. I tested this by using python openzwave which is what they use and I used it to get events from the light. and it was damned close to instant. so it's not my controller or switch or openzwave only leaves one thing.

But i am sure because of the bloat necessary to tie all of those languages together brings the thing to a crawl if they aren't using multiprocessing or threading properly.

If i want to set up a scene to have a motion sensor turn on a light i don't want it to only happen when it feels like it and not after a minute of being in the room.

because of this it is pretty much useless.

[Foune]

My opinion is a bit different. The Domoticz UI is slow, ok. The Domoticz script engine is not satisfying, ok. But using MQTT, I get satisfying response times for "real time scenarios". Two rooms in my house are managed like that :

Xiaomi wall switch to domoticz send mqtt to eventghost that triggers some python script scenario for toggling Light 1, 2 and 3

Light 1 : triggered sending json to domoticz to xiaomi gateaway
Light 2 : trigerred sending json to domoticz sending mqtt to sonoff (Tasmota firmware)

As you can see, I could make things much shorter by listening and talking directly to the devices, but actually the response time is neglictible, so I let domoticz manage my devices, which is comfortable. Domoticz and eg are running on a VM running on a windows host powered by a small ivy bridge low energy CPU. But I don't suffer from latency on the different protocols and hardware managed by Domoticz. (RF, RFLINK, Xiaomi, Milight, MQTT). The only condition is to always use tasks in eg in order to avoid the HTTP request latency caused when using json.

I have zwave hardware but it is still boxed, so I didn't test it, I'm gonna sell it I think.

[kgschlosser]

The problem with domoticz could be how it receives the events from python openzwave. since all of my lights locks and security is zwave i have to use something that deals with it. And I have yet to find an open source system that works well. and I purchased one dedicated controller for almost 300 USD that turned out to be a complete waste of money so I am very leery of spending more money on another solution to end up with the same results. I have started writing a control program that will only do zwave and that's it and have an API so that it can be communicated with from EG or some other program. But because of the complexities of it. it is going to be a while before I am done.

domoticz is not a bad piece of software and has some rally cool features but the way things are put together seems like it's patched together I tried going through some of the code to see if i could find the problem. but because of the crazy layering of things it's hard to follow. I would hate to have to find/fix a bug in it.


As far as the zwave stuff that you have. what do you have?? I might be interested in it... send me a PM with what ya have and what ya want for it. and if you would be willing to piece it out or not.. I have been doing a lot of work on my house and need a bunch of components I would rather give my money to a fellow EG'er then to a company.