New user-def app & driver code- what and how to update?

  1. Manual - copy/paste, save
  2. Don't know, as I don't use that specific app/driver. I'm sure others will chime in
  3. No. Although some (but not many) developers have added a notification in their apps that will indicate if an update is available. I'm still in the 'don't update an app/driver unless it adds something you need or fixes an actual problem you have' camp. Upgrading just to have the newest is pointless to me.

Once you have an app/driver installed if you click on the import button you can paste in the url for the raw code on github and save the imported code. This is remembered.
Now if there is an update to the code as long as the raw code url does not change, you just click on the import button, the url will be automatically displayed and you can import the new code.
Not ideal I suppose but it's better than copying /pasting every time.

1 Like

Close: it's remembered for apps. So that does make updating them in the future a bit easier, just still a manual process with a click of the "Import" button (and then OK or whatever it is) on each one. For drivers, currently the author has to set an importURL parameter in the definition (this is in the driver code). You can add one yourself, but it will get overwritten if you download new code that doesn't have it, and unlike apps, manually pasting in a URL to import from in the dialog box does not get "remembered."

One or both of these will likely change as Hubitat works to unify the process. In the meantime, apps should be fine once you do it yourself once, while thoughtful driver authors can make it easier for you. :slight_smile:

1 Like

I don’t use a separate app.
All of my apps & drivers have the update checking code built-in
With apps, you also have the option of automatically sending a pushover message when an update is available

Andy

1 Like

Ohhhh, I thought you had an app to notify of updates? Huh... even better then! :slight_smile: Thanks Andy!

1 Like

Perhaps you're thinking of this:

Unfortunately it's incompatible with Cobra's method, which is commentary apart from the current: The community just isn't big enough to need two mutually exclusive methods, imho.

1 Like

Yup, App Watchdog is mine. With over 20 apps/drivers to keep track of, this is sooo much easier. Even is you only use a few. :grin: Never a need to go into each app to see if there is an update or go to Github to get the code.

This has the option of turning on a device, sending a push and/or showing a list on your Dashboard. The beauty is you'll only get ONE push even if there are 5 apps that need updating.

It's compatible with who ever wishes to use it. So far only one other developer has taken the offer but hey, it's there for the taking. There is a list of developers within the App Watchdog post.

3 Likes

I'm not sure what you mean by this??
I created the original code and json calls that this app is based upon
My apps/drivers use some of the original code I posted so long ago.
I could easily throw up a json file for use with this app but don't see the point in the duplication.

Brian uses a different .json format and stored in a single Master/Leaf style.

For users, this means the appearance of a central check, isn't a central check. It's central to the Developer's that have "subscribed." Developers can support both by creating two (and maintaining two) Json files with each release.

The Cobra's Method is a distributed check. It's specific to each App/Driver. No central list for users to check. I use Cobra method, as you know, but if you have a central list for Cobra Apps, that would never include 'CSteele apps'. That's what Brian is trying to solve, I believe. But the .json files are miles apart in both actual content as well as intent.

Fundamentally it's the same issue that's haunting the central resource of available Tools (Apps and or Drivers) for users. Both Brian and I have attempted to contribute to a solution, resulting in, as someone once said.. "Crickets"

New users are left with 'mining' helpful participants in the Forum to steer them to appreciated Tools or searching, hoping they create search terms that yield results.

1 Like

There's crickets because many people don't see this as a big problem that needs to be solved. If they did they would be participating...

I have no issue manually updating drivers and apps Including the ones I develop.

1 Like

Exactly correct, but here we are in a thread started explicitly by a new owner looking for help with 'Tools.' (Community created Apps and Drivers)

Jason
I do agree that not having a central repository for all community apps/drivers is a problem
I'm just a control freak and want to control everything myself :slight_smile: :rofl::joy:
And my time is better spent coding, rather than maintaining my apps and update lists in several locations.

I also use my webserver (which hosts the json files etc) to collect usage data (Just how many people are using each app/driver) which helps me allocate my resources.

Andy

Sure. Don't misunderstand me - I'm not saying it isn't a valid position / want.

I just don't think there are many/enough developers that want to commit to a central repository system (I really don't, for instance).

Same here especially since you can get the raw URL and use it with "Import". The URL stays so you don't have to copy/paste every time.

It's fair to say that I'm using Hubitat for two key functions: converting a wired house alarm system to IoT (Konnected) and aligning that to a few other systems including MyQ garage doors and Z-Wave switches, so I can see and affect the entry points of the house from the bedroom and front door. Is the garage still open? Close the door. Did someone just come in the driveway door? Turn on some lights.

Most of these systems are not supported by Hubitat, they are from the community. I want to keep these components current and working. The community moves quickly. A few times I've seen a dashboard tile turn into an "unknown" as underlying systems change.

I'm looking for the protocol to keep current with the authors of all these parts to keep things working, looks like I have that for now.

This thread is as close to my question as I could find. If I make a change to an already running app that I wrote in the "apps code" section, what do I need to do to make it work. Is hitting the "Save" button all it takes or is there more to it.

Thanks
Bruce

In most cases the answer is "nothing," though it does depend on what you changed and whether anything you may have previously scheduled would be affected by something you changed (unlikely, but we don't know your app). Apps are not always "running" on Hubitat; they wake up and run only in response to event subscriptions or scheduled jobs (or other causes like an OAuth endpoint you would have had to have established), then go back to sleep. So the next time your app "wakes up," it will use your current code--nothing special needed on your end.

I'll add a little here from what I learned messing around with this for a few days. If I make a change to the code and save it, it does seem that the new code is executing (sometimes).

What I finally figured out was that the "initialize" module did not re-execute by simply saving the code so if there were changes there, like initializing a new state variable, there was a problem. If the changes were only in the "handler" section, it was fine. To force the "initialize" module to run (verified by lots-o-debug statements) I found that you need to go the Apps section and click on the freshly changed user app to bring up its options/input page and click the "done" button at the bottom. This seems to force a restart of the app.

B

This is not a standard app (or driver) method. When the app is first installed, installed() is run; when it is re-saved by hitting "Done," updated() is run (simply saving code will not cause either of these to run). Many people make a method called initialize() and call it from either or both of these (probably because much example code does the same--and presumably this code code does it because there are often things you want to do in both cases, so having such a method may be helpful), but this would explain why initialize() is not run on its own under any circumstance--it's just not special. :slight_smile: