Integrate deCONZ

⚙️ Custom Apps and Drivers Custom Drivers
41

Only some virtual drivers are useful - if they have no inbuilt 'smarts'. Things like blinds/shades thermostats and garage door controller all have smarts so are not just providing status - they 'act' intelligently upon it.

I have written a 'remote' thermostat for MQTT and will also release a remote shade and remote garage door. These are just totally dumb device drivers to provide status display plus a control mechanism back out with the smarts being actioned by the MQTT device or in your case would be the z-wave device

42

I think I perhaps misunderstood the scope of device support within the current code. Very early stages and it does need a lot of expansion, although that is what the first post implies. Currently button presses only.

But happily someone’s having a go at this,,

43

I just finish motion sensor and im working on lights a little more tricky being this a 2 way communication device now I don't think I will be able to use the virtual devices because I will need to use some specific attribute not available on the generic virtual devices

1 Like
44

You can use any number of named ‘data’ values, which are a per device set of stored values .. I use them for extra MQTT info like the associated topics and attribute mappings

45

where I could get some code examples?

46

Here at this page getDataValue and updateDataValue

https://docs.hubitat.com/index.php?title=Driver_Object

You can regard them as persistent (similar to state) variables stored per device. They are listed on a devices page at the bottom.

Sorry on an iPad - can’t screenshot easily. I use them in my MQTT code but it’s a 7000 line app so I think they’ll be easier apps as examples.

47

I end up writing 2 more drivers I postpone learning that way for the future

now suport for lights and motions sensors you need to update the parent and button drivers to the new version and add the 2 new drivers motion and lights

1 Like
48

Has the Parent changed? I don't see any changes, and the last update was yesterday, but the Child drivers today/

49

Yes I did some modification on the parent too but I forgot to update the github. Is now updated

1 Like
50

Thanks Sir, this is fantastic :smiley:

51

Why do you implement bri attribute instead of level in your light device driver ? The control of setLevel doesn't seem to work back to deConz ..

52

bri is from deCONZ go from 1 to 255, level on hubitat level go from 1 to 100

53

You need to scale them then...

54

is on the setLevel function
Value = Math.round(Percent/100*254)

55

I haven't looked at the code yet.. but it seems the level on deConz is updating bri (not level) and using setLevel updates level but doesn't propogate to deConz ?

56

Yes I just realize that I have to do the other conversion ones bri come from deCONZ need to update the level value too working on something else now I will get it later

57

I see you're using data values now too : :ok_hand: they are very useful to avoid abusing attributes

image

It might be quite nice to put the friendly 'name:' from deConz into the child device Label

58

level update complete github update but this is the only change around line 47 of the deCONZ_rest_api_Child_Light driver

def updateBri (updateValue) {
if (logEnable) log.debug "update updateBri: ${updateValue}"
sendEvent(name: "bri", value: updateValue)
Newlevel = Math.round(updateValue*100/254)
sendEvent(name: "level", value: Newlevel)
}

1 Like
59

Do setLevel() updates back to deConz for lights work for you (over ZigBee to the physical device) ?
I am new to deConz here so not familiar with how they're done..

parent.PutRequest("lights/${getDataValue("ID")}/state","{\"bri\":${Value}}")

PUT /api/<apikey>/lights/<id>/state
60

What is a good name you think I should use?
Not really good a that, I never take programming classes so I really don't know best practices I'm more like an obsolete mainframe admin now everything is cloud base so I turn out cable guy.

1 Like