Domoticz Bridge
-
A quick solution could be to install my own Virtual Devices plug-in and just map some HTTP calls. I'm using it to map MQTT-based things, my own virtual devices and to group them (ie: to sync dimmers or blinds). If my memory is till working, domoticz has a simple HTTP api and you could update variables very easily.
-
Allready dug my feet in.
One thing i'm struggling with is - Isn't usually (coming from VB and C++) interfaces to GUI and core more pronounced in the code layup? I.e the "variables" table for devices - this would in my head be defined as a set of variables defined one place in the code with a notation that that is where they get input/can be read/manipulated?
The panels underneath the "Control panel" tab are defined in the I_...xml, but again i don't se an overview of the variables used there in the .Lua?
I'm by no means a professional programmer, but this makes the learning curve a bit steep.
-
Bizarrely, the variables don’t appear in the .lua file and aren’t directly accessible by the plugin itself. You have to resort to using the same luup.variable_get() function as any other code would to access the device. This is something I fixed when writing openLuup.
-
Partly in the service files which the device/implementation .xml files use, and partly dynamically. Anything, anywhere , can create a new serviceId/variable on any device. That's why the 'documentation' here:
http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_device_supports_service
says:
"Setting UPnP variables is unrestricted and free form, and the engine doesn't really know if a device actually uses it or does anything with it."
-
I started with the latest VeraBridge and rebuild that to an EzloBridge (with some help from ak). VeraBridge has only a .lua file and all other files are sort of build in the openLuup virtual file system. You will have to make your own copies just as for a normal plugin. You can look at EzloBridge for some ideas https://github.com/reneboer/EzloBridge/tree/master/src
I can tell you it is tricky to do, but doable.
Cheers Rene
-
I got the domoticz bridge up and running, though still with many flaws to iron out..
@akbooer: Is x_BarometerSensor1.x definition a part of Openluup installation?
I got it with the Zigate plugin I think.. If not, mabye add it?
I can push it with the domoticz update as well, but it might as well be with OpenLuup? -
I got the domoticz bridge up and running, though still with many flaws to iron out..
@akbooer: Is x_BarometerSensor1.x definition a part of Openluup installation?
I got it with the Zigate plugin I think.. If not, mabye add it?
I can push it with the domoticz update as well, but it might as well be with OpenLuup? -
I actually created one such device class with a specific icon based on the generic sensor. I probably posted here somewhere as I used it to bridge zigbee devices from home-assistant....
-
It's getting ready now, and I uploaded a "release" to github in a fork from the original. Do I have to upload to the original repository to make it available in AppStore?
@akbooer: This plugin has a script that is run in domoticz to get async updates. How is that done in zway/vera bridge? (in short, and laymans terms please)
-
It's getting ready now, and I uploaded a "release" to github in a fork from the original. Do I have to upload to the original repository to make it available in AppStore?
@akbooer: This plugin has a script that is run in domoticz to get async updates. How is that done in zway/vera bridge? (in short, and laymans terms please)
@perh said in Domoticz Bridge:
This plugin has a script that is run in domoticz to get async updates. How is that done in zway/vera bridge? (in short, and laymans terms please)
Sorry, not quite clear what you're asking here. Can you expand on this?
-
I C, but then, "asyc poll" is just that it sends a report immediately on changes done in openluup, but changes on Vera will not be updated until next polling round?