Domoticz

• Plugins now have separate event queues so if one crashes Domoticz the stack trace will identify the culprit
• If plugin debugging is enabled (debug mask '2') then exceptions will write the values of local and Domoticz variables to the log
• Connection objects now have an optional timeout (ms) that will fire an onTimeout event
• Connection objects can now have an event target specified during Connect or Listen operations. All events for the connection will be sent to the specified object

• A new extended Device object not keyed by Unit (so not constrained to 256)
• Ability to override the class that Domoticz uses to store Devices to allow better encapsulation
• Direct callbacks to Device objects on addition, modification or deletion

class KodiDevice(Domoticz.Device):
    def __init__(self, DevicelID):
        super().__init__(DevicelID)

	#class variables 

    def onCreate(self):
        Domoticz.Debug("Device onCreate called")

    def onUpdate(self, Previous):
        Domoticz.Debug("Device onUpdate called")

    def onDelete(self):
        Domoticz.Debug("Device onDelete called")

Domoticz.RegisterClass(Device=KodiDevice)

• In the extended Device class, simply expose relevant DeviceStatus details in a simple dictionary with DeviceID/Unit as the key
• Create a new Device class keyed by DeviceID that has minimal data and holds a dictionary of Units (keyed by Unit) that have the relevant fields from DeviceStatus

x = Devices[DeviceID+UnitID].Value

x = Devices[DeviceID].Units[UnitID].Value

class KodiDevice(Domoticz.Device):
    def __init__(self, DevicelID):
        super().__init__(DevicelID)

        self.kodiConn = Domoticz.Connection(Name=self.Name, Transport="TCP/IP", Protocol="JSON", Address=Parameters['Address'], Port=9090)
        self.kodiConn.Connect(Target=self)

    def onUpdate(self, Previous):
        Domoticz.Debug("Device onUpdate called")

    def onConnect(self, Connection, Status, Description):
        Domoticz.Debug("Device onConnect called")

    def onMessage(self, Connection, Response):
        ...
        this.Units[0] = "Playing"
        ...
        
Domoticz.RegisterClass(Device=KodiDevice)

Dnpwwo wrote: ↑Saturday 13 March 2021 5:59 The next change will be to create some new objects that will allow plugin authors to have much more control and that provides a better mapping to more modern hardware types. Specifically:

• A new extended Device object not keyed by Unit (so not constrained to 256)
• Ability to override the class that Domoticz uses to store Devices to allow better encapsulation
• Direct callbacks to Device objects on addition, modification or deletion

Dnpwwo wrote: ↑Saturday 13 March 2021 5:59 I have a question for this thread though: What is the best way to expose DeviceStatus details to plugins?

I see two possibilities:

• In the extended Device class, simply expose relevant DeviceStatus details in a simple dictionary with DeviceID/Unit as the key
• Create a new Device class keyed by DeviceID that has minimal data and holds a dictionary of Units (keyed by Unit) that have the relevant fields from DeviceStatus

I don't have strong feelings either way but prefer the second because I feel it more accurately reflects modern devices where one physical device has multiple values associated with it. The last single Z-Wave device I bought had 10 different things it reported for example.

Thoughts?

Dnpwwo wrote: ↑Saturday 20 March 2021 9:31
@pipiche,

I was planning on making minimal changes so wasn't planning on playing with the update but maybe I can look when the dust settles.

My current thinking is to create a new Domoticz import called something like

Code: Select all

import DomoticzEx

that uses the different Device and Unit structure so that it's easy to use the new functionality and easy to maintain backwards compatibility.

Dnpwwo wrote: ↑Saturday 20 March 2021 9:31 @heggink,

I do have a ZWave Python plugin but it is pretty rough. It works with the ZWave Gen 5 stick from Aeotec, not sure about other sticks (not the S2 though).

It should work with the upgraded framework, I'll make it available if it does.

heggink wrote: ↑Sunday 21 March 2021 10:36

Dnpwwo wrote: ↑Saturday 20 March 2021 9:31 @heggink,

I do have a ZWave Python plugin but it is pretty rough. It works with the ZWave Gen 5 stick from Aeotec, not sure about other sticks (not the S2 though).

It should work with the upgraded framework, I'll make it available if it does.

@dnpwwo: VERY interested. Any chance I can gave a look (I have the gen 5 )? Also, what framework is it based on? zwave-node-js by any chance? If so then that would be brilliant since it seems to be the next generation ozw successor...

moroen wrote:

heggink wrote: ↑Sunday 21 March 2021 10:36

Dnpwwo wrote: ↑Saturday 20 March 2021 9:31 @heggink,

I do have a ZWave Python plugin but it is pretty rough. It works with the ZWave Gen 5 stick from Aeotec, not sure about other sticks (not the S2 though).

It should work with the upgraded framework, I'll make it available if it does.

@dnpwwo: VERY interested. Any chance I can gave a look (I have the gen 5 )? Also, what framework is it based on? zwave-node-js by any chance? If so then that would be brilliant since it seems to be the next generation ozw successor...

Perhaps we should split this into it's own topic, but do you have any thoughts on how a plugin with zwave-node-js should work? I've taken a quick look at Zwavejs2Mqtt, based on zwave-node-js, and creating a plugin using MQTT with zwavejs2mqtt as a backend looks manageable, as much of the "hard work" has been done...

Regards,
M