Domoticz general architecture

[stefaanv]

Hi,

I've been playing around with domoticz for a couple of months now and I am very impressed about it.
So far I have
- Written a Python interface between Domoticz and the Wago PLC's that control my lights and blinds
- Installed RFXcom and Mysensors gateways
- Played around with some of the Mysensors examples.

However, I'm having a hard time grasping the master/slave devices and some of the scripting concepts.
During my Domoticz "research", more and more I get the feeling there is something weird in the general architecture.
Having thought long about is, here is the best way I can put this feeling into words:
"The concept of sensor -> control -> actuator is missing". I believe that because sensor, control and actuator are mixed up in the "device" concept, things like master/slave are needed. I also believe Domoticz would become easier to use and understand if the sensor-control-actuator concept would be introduced.
Are other people having thoughts about this ?

Stefaan

[toreandre]

I would love to set "if condiotions" directly on a device instead of going to blockly/lua everytime.
example: On a temperature device i would like an option to activate/deactivate other devices based on max/min temp.

Dont know if this is what you mean?

[juankar]

Impressed!!! You speak about "the architecture of Domoticz", where have you found any info about this architecture and about the way domoticz works? I'm trying to modify some code in Domoticz and I have to make a lot of "reverse engeniering", I've needed hours for understanding, just a bit, this software.
I see a lot of code but I can't see the logic. and I would like to find something about it.

[stefaanv]

I will try to clarify my view with an example :
Assume you want to set up a switch that activates/deactivates a light only if it is dark outside and saves one camera frame to disk when it changes the light activation. The light can be activated independently in the GUI.
Sensors/input : switch, lux sensor, camera feed, GUI tile input
Actuator/output : light (relay), save camera frame to disk, GUI tile status output
Processing : when the switch pressed while light is off and lux is below xyz, switch on the light, update the GUI tile status and save a camera frame to disk, .... Maybe also send a message to a log file, ...

I understand that the processing part is the most difficult. For anything other than the most trivial examples, you'll need some kind of programming language. This could be a graphical language like blocky or node-red. Simple/common scripts could be handled with wizards that help people who do not like to program.

Stefaan

[stefaanv]

@Juankar,
I'm impressed by the out-of-the-box functionality of Domoticz. Got nice features out of it in no time.
With "architecture" I mean the general functioning of the programming which - I suppose - reflects the internal software architecture.
I'm trying to give positive criticism. I'm not a C++ programmer, so I'll keep away from the code.

[Egregius]

I can only recommend learning a programming language.
The simpliest things are possible with blockly.
If you want more advanced stuff best thing to do is program it in lua, php, shell,...
All such things are so user based that you can never get all options in a GUI.

[juankar]

@stefaanv
Ah, I thought you were talking about the internal architecture of Domoticz. That's: source code and so, and of course C++.
And yes, you are right: we can do a lot of things using lua, or python or php or Shell scripts. From very simple tasks till sophisticated actions. Because of that (and other characteristics) Domoticz is a great product.
But I woul like to see documentation about the internal working of Domoticz, so perhaps more persons could make improvements or develop new features or just fix bugs... (I have to say that I like learn about the "how to"... )
Althoug I know that to document a software like this needs a big effort.

Now I'm refreshing my C++ and updating myself, just as a hobby.

[niceandeasy]

Domoticz Master/Slave and the KAKU example:
If you have two KAKU button sensors (for example, on the wall and on a remote), and one KAKU switch relay that listens to both buttons. Domoticz needs to listen to both buttons to know the state of the relay. For that, Domoticz needs two 'switches'. And to connect those two in Domoticz, we make one of them slave from the other one.

I like the sensor/actuator roles are mixing. It allows for more flexibility. In hardware, I also see this mix: some relay switches have buttons on them for switching.
And there's plenty of control possible in the LUA scripting.

Scripting: keep in mind, Domoticz is event-driven. If something happens, Domoticz will start the appropriate LUA-scripts. The scripts take input from some arrays that are filled by Domoticz. The script will need to test what changed, do the "control" and pass the actions to the commandArray. Domoticz will execute the commandArray after the script ends. And for the simpler "control" tasks, Blockly can be used.

Indeed, very impressive.

[jensc]

There are features in other HA applications that are certainly worth "emulating". For example, within InControl (now Axial Systems) there is, on each actuator device configuration screen, a button that says "mirror". Click it and you can add as many devices as you wish to mirror the actions of the current device. These actions can be logically same or inverted... very handy... and without any programming. Turn on one light and have 8 others turn on also.

One can download the source for Domoticz but sussing out the architecture, without documentation, from that alone, is no mean feat, to be sure.

[juankar]

Mmmm... but doesn't Groups work so? In a group you can switch On/Off several devices, can you?

[jensc]

Mmmm... but doesn't Groups work so? In a group you can switch On/Off several devices, can you?

Probably not the best example. That particular feature has much more "logic" and "smarts" built in, though, than Domo groups.

My primary point is if trying emulate that feature with source code it is much easier with architecture documentation as the original poster implied.

[juankar]

You are right: documentation of Domoticz is very poor. It's good for an ordinay user, but if you want to make something more elaborated or modify source code you need hours of study... and don't forget source code is C!!!! the more uninteligible programing language
Anyway, it's a very good software.

[Kenedy]

I have the same idea of juankar's.Follow his tips and advises...

[jensc]

@kenedy

"Graduated from Soran University with First Class Degree with Honours in Computer Science."

Well done!... Congratulations!

Jens

[MarcusDomus]

I agree wit topic starter, Domoticz is great but lacks developer documentation. At least I can't find it. Would be very nice to add a developer oriented section to the wiki to document the architecture. My experience is that each developer/contributer will get its own view on the architecture causing incompatibilies and spagetthi code. If contibutions from the public domain are welcome documentation is neccesary. Personally I would like to see how devices are strucured and some tables with device classes and their properties. E.g. I am using a dummy rain sensor but don't know all properties and how to differentiate between rate and mm. Once started, others could help by contributing what they reversed engineered. But now I don't know where to start and what principles ase leading in the architecture and design.

[Sine]

Hi stefaanv,

Do you have any info about your WAGO - Domoticz link ?

I have a 750-481 kicking around that I would like to use to control lights and shutters, but I have no idea how to implement this.