Driver Life Cycle

🚧 Developers Coding Questions
1

Hello All! I was gifted a Hubitat Elevation for Christmas, and am finally getting around to using it. I am new to HE and Home Automation in general. However, I do have some software development experience.

Background:
I am trying to develop a device driver to control some cheap Feit Electric bulbs that I got at Costco.
https://www.amazon.com/Feit-Electric-Smart-Changing-Dimmable/dp/B07RL48PFF/ref=asc_df_B07RL48PFF/

I installed/flashed the bulb with Tasmota 8.0.1.2. As of right now, I am planning on using HTTP, but might switch over to a MQTT based solution depending on how well this works. This is what I have so far: HubitatAppsAndDrivers/TasmotaHttpFeitBulbDriver.groovy at master · megbers/HubitatAppsAndDrivers · GitHub

I got this far by basing the code off of others work and modifying as needed. I can get it turn off and on and set the color of the bulb and have it sync to the color with that of the Color Bulb tile in the DashBoard App. (I do have a javascript error in the dashboard I created, but I will post that to a different topic)

Now for my question:
I can tell, obviously, when the on() method is called from the UI, but what I cannot tell is when the refresh() or ** initialize()** methods should be called. I have also seen some examples with update() methods implemented. Does anyone know if there is any documentation that I am missing about when these methods will be called and/or what they should be doing? I have found the "java doc" type documentation for the the Capabilities, but that really doesn't tell you much besides the method signature.

When and by what do those methods (initialize, refresh, update) get called. I can call them manually by going to the device screen and clicking the buttons, but shouldn't those be called automatically by the framework? I am doing something wrong in my code to prevent those methods from getting triggered?

Same thing with the parse() method. I can tell by the logs that it is getting called, but my code doesn't explicitly call it anywhere. So, something is calling that method some time after the HTTP request is complete. Is that called by the hubitat.device.HubAction class or the framework?

NOTE: I could be thinking about this totally wrong, too, so please be gentle.

2

So, after some research, it looks like all the documentation for SmartThings more or less holds true for Hubitat. Can anyone confirm that is true or not?

For instance this seems to answer most of my questions: Overview — SmartThings Classic Developer Documentation

3

Welcome to Hubitat!

Yes, the ST Classic Developer Docs can be used for most Hubitat Apps and Drivers. However, there are some notable exceptions. Take a look at the Hubitat Developer docs as many of the Hubitat specific items are well documented there.

Also, take a look at this thread...

4

Initialize() is called when the hub starts up. Useful for reestablishing communications after a reboot. Examples are connecting a webSocket or Telnet session.

Refresh() is never automatically called that I am aware of. An App can call a device’s refresh() command if necessary.

Update() gets automatically called when a user clicks on SAVE for the user preferences.

Installed() gets called when the device is initially installed.

1 Like
5

Best Christmas gift EVER! :heart_eyes:
Welcome to the community! :palms_up_together:
RogerThat

1 Like
6

Cheesh, would of saved you a ton of time buying compatible lights. LOL

7

Maybe he likes coding and learning about the system? I do, which is why I wrote my own drivers :stuck_out_tongue: I think that goes for a lot of devs. Btw, for that device there is a working driver, but that is probably beside the point.

EDIT: To stay on topic a bit, if you don't want to go the MQTT route but still don't want to use polling to know the state of the device (not really important unless you control it directly, but anyhow), you can use my modified Tasmota firmware which calls back to parse through http instead of MQTT.

2 Likes
8

True dat but you may have just ruined his day. LOL
Although I’m sure that other working driver will be a good reference :+1:t3:

9

I really hope not!

Not too sure about that, my drivers are unnecessarily complex as examples, they're stitched together by a build-script etc... There are MUCH better examples on how to do things.

1 Like