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..
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.
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.
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. (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. But I think it was pretty common on ST and thus seen in a lot of ports.
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