Use of Global variable (or equivalent) in groovy Device Handler

🛎️ Get Help
1

I'm migrating an HTTP driver that I wrote on Smartthings over to HE. In Smartthings you are not allowed to have a Global variable (global being global within the DH) but there was an easy workaround. Instead you would just define some extra tiles that did not show on the interface and change their values which could be referenced from anywhere. A little clumsy but it worked well.

So now I'm on HE and tiles are ignored, they simply don't exist. I thought I would use attributes instead but the updates to these are asynchronous rendering them unsuitable for this purpose. FYI you also can't use state for this purpose.

I'm sure someone will say well why do you need a global variable so here is the use case. The device handler sends commands via HTTP to Tasmota devices. The response from the Tasmota device comes back to the parse() function asynchronously. If you know the commands that were sent to Tasmota you can then compare those to the results received and thus you have positive confirmation that a command was successfully executed. So the global variable is used to store the sent commands and allows this comparison to happen. So it is basically a transacted operation that keeps the UI in sync with the actual device.

I'm new to HE so I'm hoping there is some difference in the Groovy implementation\restrictions or some other mechanism that will let me achieve this same result. Perhaps including some library or something. Any help very much appreciated.

2

State and AtomicState?

I'm reading your message and thinking AtomicState was invented for this. Since both are available with ST, I'm sure you thought it through and discarded it, but didn't mention it.. too obvious? but not to me? :smiley:

3

Two things, asyncHttp can achieve what you want without storing anything in a global variable. Second, there's already a few Tasmota drivers available for HE, what will yours do which is not already done?

4

Thanks for the response. AtomicState would work but its not available for DH's. With state, if I change the value of state.variable in function A and then read the value of state.variable in function B it does not have the updated value. State keeps reading the original value from the database because State only gets updated when the DH terminates.

5

Hi Markus, Here is a link to the Smartthings version of my DH [Release] Tasmota Comprehensive RGBCCT Device Handler w/MQTT for SmartThings Classic - V1.1 - Devices & Integrations - SmartThings Community

I don't know what I will port over exactly but the main thing mine did was to transact requests so that the UI did not update until a confirmation was received. All the other Tasmota drivers I have seen don't do this so things get out of sync easily.

What I think I would bring over beyond the basics is preset colors, preset whites, fade and MQTT support plus exposing a number of Tasmota variables to HE. But the main thing is really to have confirmed transactions. Might not matter much for lights but I also have a similar driver for Tasmota plugs and I really need to know if downstream devices are being successfully turned on when requested.

So you say it's possible using asynch HTTP without a global variable. So lets say that I send Tasmota the command "COLOR 000000461B" and I get this back in parse:
{"POWER":"ON","Dimmer":27,"Color":"000000461B","HSBColor":"0,0,0","Channel:[0,0,0,27,11],"CT":250}

How do I let the parse function know what was requested (without using a global variable) so that I can compare it against the actual result?

6

If this is what you want, my Tasmota driver does this, it does not compare to the command sent, but it does not update state (or the UI) until that state is sent FROM the Tasmota device. In no case is the UI out of sync with the device.

My RGBTCCT child driver does most of this, it would be trivial to add more features to the child driver, and this could be done without implementing a whole new driver, all you would do would be to add the Tasmota commands to the child driver and let the parent do all the heavy lifting.

This is on the roadmap for my unreleased Closed Beta driver (it is stable and actually production code used by quite a few people already, just lacking complete documentation), it's just a matter of lack of time so far, I'd appreciate any pull requests and help to add that. I'd be happy to discuss this more if you're interested.

This is guaranteed by the design of my driver.

You could put it in the "data" parameter of the async method.
With that said, I do not see the need to check against what was sent. What is important is to not update state until Tasmota reports state. The only circumstances in which Tasmota wouldn't have set state according to a command is if it didn't receive it, ie a dead/offline device (this is detected in my driver through a heartbeat timeout) or if multiple commands were sent at the exact same time (race-conditions could occur here, but state would still be whatever the last command that was executed by the Tasmota device is). With this said, if you would find a case where you don't get the state your command is supposed to set in the Tasmota device, that would be a bug in Tasmota that needs fixing.

There are more intricacies and reasons as to the hows and whys here, I'd be happy to discuss it further.

I hope this clarifies some things, I'd also hope you would consider improving and adding the features you need into my driver rather than adding one more driver to choose from that makes it extra confusing for new people to get started with Tasmota. I'm open to discuss this more, feel free to PM me :slight_smile:

EDIT: I looked some more at the ST DH, a big part of the features it provides are the custom tiles, this is functionality which doesn't exist in HE natively, but there are, hacky, ways to implement most of it.

7

Markus, thanks for the detailed response. I understand what you are saying with reference to using events in parse() to do the work and I like that approach. FYI One thing my smartthings driver did was prevent race conditions by blocking input until the response was received or the request timed out. It was also helpful for letting a user know when something was offline.

I only installed my hub on the weekend so I'm not yet 100% committed to Hubitat but I'm enjoying experimenting and seeing what is possible. I find the dashboards functional but rather crude and the interface for devices even worse. But I like that it is all local and it has a decent set of apps but could be a bit broader. I have a SharpTools account also so I can dress up my interface when needed.

I have not tried your driver yet but I will give it a go. It looks like you have some hooks into a customized version of Tasmota which could be interesting although perhaps a challenge in the longer term keeping new releases of Tasmota firmware up to date.

Thanks for the offer to collaborate. I just code for fun (no formal training) and like the freedom to write whatever I want so I'm probably not a good candidate as a collaborator. But I'm always up for sharing ideas as we have a mutual interest in Tasmota and Home Automation.

1 Like
8

With Tasmota the last command "wins", the firmware is well written and handles rapid commands well, I'd trust Tasmota to handle this much more than I would any hub. As far as the offline part, I have that based on the periodic status messages pushed from Tasmota.

I've never used ST, but from what I've read from others here I doubt you'll ever want to go back once you've experienced the speed and reliability of controlling lights locally. You can always just link your HE with ST if you want to still use something specific on ST but have the local benefits of HE for most things. I've seen people mixing and matching a lot.

Crude would be the understatement of the year, there's a nice mod to make it at least look nice, have a look at Smartly.

I do use a custom firmware, I update to the latest one when there is a need and there is an official release build. I will update to 8.2.0 soon, just been very busy. For most things there really isn't a need to run the latest version, but there are some nice things in 8.2.0.

I understand, if you want to code using my code-base I'll explain some more about it, it is using some python scripts to "build" apps and drivers from a common codebase in order to avoid having to copy and paste code around. If you do want to add some functionality but do so in your own style, I'd recommend looking at making a child driver, that could be done 100% independent and doesn't even need to be based on my code, but you could still make use of the parent code without ever having to touch it. For the closed beta, if you want access, just PM me.

9

Hey Markus, I took a look\installed your Tasmota Connect and a couple of drivers last night. Flashed a few devices with the Hubitat 8.1 version and I was off and running.

I must say that I am very, very impressed with how much work you have put into this, very high quality and really well thought out. I will be interested to see what the future brings.

Your solution was light years ahead of mine so I'm going to skip doing anything with it on Hubitat. I would be doing HE users a disservice to do anything that would steer them away from your solution.

The only thing I had trouble with in the instructions was realising that I had to install the code for Tasmota Connect, where to find it and how to do it. As a brand new user it was not immediately obvious although I'm sure it is to anyone that has been on HE for a while.

image
image806×216 12.2 KB

Today I flashed the rest of my devices and now all Tasmota devices are in HE. The only thing I noticed was in the "Tasmota - Generic Wifi Switch/Light". The Current States did not show the switch state, although I could turn the device on and off normally.
image

Other than the autoconfigure (and perhaps autodiscover) what else does the custom firmware do. Perhaps it is just a bridgehead to future capabilities at this point?

I did have a few ideas that I will share with you some other time but mainly I just wanted to give you two thumbs and and a big thank you. You made my home automation so much easier and manageable.

1 Like
10

Hi Gary, glad you like it! You didn't ask me for the Closed Beta access, but I went ahead and added you, you will like that one even more, anything extra you want in terms of presets or special commands you can add that to a Child Device driver easily, all without having to deal with any of the Parent driver complexities.

I did spend a bit of time on this, the origins come from another user I took over this project for end of last year, but I've rewritten everything in the Closed Beta. I appreciate you saying this, there are those that don't like using my custom firmware for some reason, but that's their loss.

The documentation is lacking, I have some people who have volunteered to help with the documentation, but they've not had time yet. It'll be updated eventually. This lack of documentation is the only reason the new driver still remains in Closed Beta. Code-wise it's stable and ready.

The Hubitat IP settings of the device must not have been set properly, try pressing "Configure" again. There might be some minor bug still in that driver where it doesn't catch all corner cases, but the new driver should auto-configure the device properly. You may still have to press "Configure" on the driver page in some rare cases, but that will then be it.

The custom firmware I keep as close to original Tasmota as possible, the differences lay in how updates are pushed to HE directly instead of using MQTT. What is done is that the JSON message normally published to MQTT is sent via http directly to HE when an event occurs, so just as instant as MQTT. In fact, that message arrives and is processed even before the return call of an asynchttp-operation, so it is very fast.

The only major thing that still needs implementing is a solution to get rid of the "popcorn" effect when turning on multiple lights at once. There's also some more things in the TODO-list in the Closed Beta thread.

I'm happy to listen to input :slight_smile: Again, I'm always happy when someone likes my work, I'm just sorry you'll have to redo some installs to get the newest Closed Beta driver, at least the firmware remains the same, just the HE App and Driver is different.

EDIT: @garyjmilne if you post links to the devices template pages from https://templates.blakadder.com/ for the devices you use, I can add them to the configure list in the app and driver.

11

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.