Driver coding question with sendEvent

I am playing around with a custom driver and looking at an example that has the following snippet of code: (if there is a better way of including a snippet let me know as well)

So the 'sendEvent' statement is setting the value of the variable powerDisp as well as creating an event record for the device.

What is the statement in brackets doing??? It appears to be setting the value of the variable powerOne and somehow this has an event record as well for this variable..

if (newValue != state.powerValue) {
dispValue = "Total\n"+newValue+"\nWatts" // Total watts label
sendEvent(name: "powerDisp", value: dispValue as String, unit: "", descriptionText: "Display Power: ${newValue} Watts", displayed: false)
state.powerValue = newValue
[name: "power", value: newValue, unit: "W", descriptionText: "Total Power: ${formattedValue} Watts"]

if thats the complete code block then the line with the brackets isn't doing anything.
there are hubitat code examples here:

For each device, on the device info page, there's a State Variables area that gets populated with anything the developer wants:

Screenshot 2023-05-08 at 3.54.49 PM
In this example the developer wanted to save the timestamp of the last bettery update and something they are calling wakeInterval.

In your case, if you look at State Variables, you'll find powerValue and what looks to me like the components of an Event.

Yes I believe I understand the sendEvent command correctly, but the bracket command just stumps me... Is that a valid syntax for something?

Sorry but a programmer from eons ago... Used PASCAL and assembly language back in my day so the syntax and the commands are a bit new to me.

I will take a look at the examples.

Your last line with the brackets is just a way to format a "Map". When your target function takes a Map as an argument you can send it with or without the brackets. Groovy is very lax and flexible, which can also make the syntax confusing because different examples will have different syntax.

Here is your code fixed, showing both ways.

if (newValue != state.powerValue) {
    dispValue = "Total\n"+newValue+"\nWatts" // Total watts label
    sendEvent(name: "powerDisp", value: dispValue as String, unit: "", descriptionText: "Display Power: ${newValue} Watts")
    state.powerValue = newValue
    sendEvent([name: "power", value: newValue, unit: "W", descriptionText: "Total Power: ${formattedValue} Watts"])

Side note - it is not needed to "filter" out events based on the previous value. You can just send the event every time and the hub will (mostly) ignore it if the value has not changed. You can override this by using the "isStateChanged: true" property in the arguments for sendEvent which will force the hub to consider it as changed.

2 Likes

What I think was going on in the original code is that the Map was a manually-created event map, as an alternative to createEvent(). If returned from parse(), this would generate an event in the platform without needing to use sendEvent() yourself. Instead, this driver (or maybe DTH?) is doing both, likely because the author got confused. :slight_smile: (Recall also that Groovy doesn't need the return keyword, so if this was a method and this was the last line, it would have been the return value--though we'd really need more context to say.)

This is also why I just use sendEvent() myself instead of relying on this chain of return values. :smiley: But I think it was pretty common on ST and thus seen in a lot of ports.

1 Like

Yeah I think I saw have seen that in one other driver, was very confused. One more reason why Groovy is flexible yet confusing.

Yes I believe this was a ported driver from ST so some of the coding practices carried forward. I believe bertabcd1234 response is correct on the assumptions. The bracketed statement was updating the variable as well as creating an event.

Also good to know that I don't need to filter and that the hub will ignore sendEvents if the value has not changed...

Thanks for the responses as this has cleared up some of my confusion. I also need to learn more about Groovy to better read the code.

I don't like lax and flexible languages as they allow me to code myself into a mess..... hah