Change request - trigger on Hardware IDX [Solved]

[ronaldbro]

@Waaren,

I have a change request for dzVents. I would like to have a trigger type on any device part of the same hardware.
I propose the following new section:

Spoiler: show

on = {

-- device triggers
Hardware = {
-- scripts is executed if the hardware of a device that was updated matches with one of these triggers
'hardware name', -- hardware name
'abc*', -- triggers for all devices of which the hardware name begins with abc
258, -- id
},
}

I have two use cases for it at the moment:

1. I use the Battery Levels plugin from Xorfor and want to create a script notifying me when the battery level of a device is below a certain level, when it decreases too quickly or when the last update is too long ago. By having a trigger on hardware idx new battery level devices are taken into account automatically.
Sure I can do that with some naming convention on the device, but it would be more safe to use the hardware. Next to that it can take a while when the new battery level device is created.

2. I have some Mi Flowermate plant sensors and want to create a script to get notified when action is required. By using the hardware idx new plant sensors are added automatically to the script.

What do you think, is it feasible and do you like the idea?

Regards Ronald

[EddyG]

There are some scripts (lua) which enumerate all hardware devices and signal when battery level is under a threshold.
There is even a plugin.
Is n't that enough? I works for me.

[ronaldbro]

Haha, what’s enough. There’s no innovation when we only use what there is
I really like dzVents, I prefer to only use dzVents. It let’s me do everything how I like it. An the hobby is making it work how I want to...

[waaren]

I have a change request for dzVents. I would like to have a trigger type on any device part of the same hardware.
What do you think, is it feasible and do you like the idea?

Thx for the suggestion. I understand why you could use it and without doing much of an analysis I guess it would be feasible but I don't think it will be implemented. At least not in this way.
If you look at the options in the on = section you see that they all have in common that an event targeted at the object referred to in this section occurred.

examples:
on = timer -- a time event will trigger scripts of which the time rule evaluates to true
on = devices -- a device event will trigger scripts of which the device targeted in the list of 'changed' devices received from domoticz
on = customEvents -- a customEvent will trigger scripts of which the customEvent targeted is in the event list receive from domoticz

etc..

If you follow the same logic on = hardware -- would be an hardware event of which the hardware caused an event but in fact you want the script to be triggered on a device event.

But again thx for the suggestion. Certainly worthwhile to discuss with the other developers of dzVents.

[ronaldbro]

I understand your point. In this way there should be a hardware object.
But thinking of it, that might even be useful...

domoticz.hardware(idx/'name') which returns a hardware object.

Hardware object contains:
- idx
- name
- devices(idx/'name')

And the device object could have a reference to the hardware. For example:
domoticz.devices(25).hardware.name would return the name of the hardware or the device...

Just thinking along

[waaren]

Hardware object contains:
- idx
- name
- devices(idx/'name')

domoticz.devices already have some information about the hardware where they belong to since dzVents 2.2.0 (see example)

In build 12068 (dzVents 3.0.6) the function domoticz.hardwareInfo is available. See the wiki

Example script:

Code: Select all

return 
{
    on = 
    {
        devices = 
        { 
            'hardwareTrigger'  -- change to name of your trigger device
        },
    },

    logging = 
    { 
        level = domoticz.LOG_DEBUG,
    }, 

    execute = function(dz, item)

        dz.log('item.hardwareName: ' .. item.hardwareName, dz.LOG_DEBUG)
        dz.log('item.hardwareId: ' .. item.hardwareId, dz.LOG_DEBUG)
        dz.log('item.hardwareType: ' .. item.hardwareType, dz.LOG_DEBUG)
        dz.log('item.hardwareTypeValue: ' .. item.hardwareTypeValue, dz.LOG_DEBUG)

       dz.utils.dumpTable (dz.hardwareInfo(item.hardwareName)) -- Dumps the formatted result of hardwareInfo() to the domoticz log 
       dz.log(dz.hardwareInfo(item.hardwareID), dz.LOG_DEBUG) -- Dumps the result of hardwareInfo() to the domoticz log as JSON formatted string 

    end
}

[ronaldbro]

Thanks, didn't know that.
That would give a posibility to itterate through the devicelist and filter on hardwareId. It's not the same, but very helpful

In that case it may be a possiblity to add a function in the device trigger, just like in the timer trigger. In the function you could easily check the hardwareId. Or do you think it will give a possible performance issue?

[waaren]

Thanks, didn't know that.
That would give a posibility to itterate through the devicelist and filter on hardwareId. It's not the same, but very helpful

In that case it may be a possibility to add a function in the device trigger, just like in the timer trigger. In the function you could easily check the hardware Id. Or do you think it will give a possible performance issue?

I don't think this will add real value.
If you would use the full name of the device or wildcarded string of the devicenames you would already know the hardware.
If you use '*' ( all devices), the check has to be done anyway for every device event. The advantage of checking this in the dzVents runtime modules compared to adding this check in the script logic does not outweigh the effort to implement and the burned CPU cycles for this feature.

[ronaldbro]

Didn't think of using '*' in the hardware trigger to get triggered on all devices. I only use idx in the device triggers, they don't change... But I agree, this would be the same as adding the check to the execute part of the script.
And it would be a huge amount of checks looking at the amount of events from some of my devices.

For now I have enough workarounds to play with, but it would be great if something like this would be added

Thanks for your explanations waaren.