Hub error 500

Correction:
which should not happen anymore and should be immediately reported TO HUBITAT SUPPORT

2 Likes

You are correct. Patrick is monitoring this thread though.

Out of curiosity - Your screenshot looks like the Preferences section of a device, rather than a rule. Here's what I see when I choose Send the HTTP Request action when building a rule:

If your screenshot isn't from a rule, then what driver is that? I ask because I am not sure how to correctly set up a rule to send a basic HTTP post that's needed.

Here's an example I have setup already. Of course you will need to replace "shutdown" with "reboot".


Also this rule is being used to control my main hub from my Dev hub. If you are creating the rule on the hub you need to reboot, you will need to use port 8080 like @SmartHomePrimer mentioned above.

You can also use a driver like @ogiewon's http driver below

Hubitat/Drivers/http-momentary-switch.src/http-momentary-switch.groovy at master Β· ogiewon/Hubitat Β· GitHub

6 Likes

@stephack how are you monitoring the battery? How is it connected to hubitat?

I have a Qnap Nas that is USB connected to my ups. The Nas has a built in NUT server.

@ritchierich made an awesome driver that connects to this NUT server that captures the battery states.

QNAP NAS Integrations for UPS Monitoring, NodeRed, Home Bridge, etc

It's really pretty easy to setup if you have all the right equipment.

1 Like

Haha ooof course. I updated to .115 the other day and things were working very well. These minor revisions kept coming out and I thought to myself "best not to break what's working. I'm gonna wait until this weekend to check the forums on how these updates are doing".

Woke up to a 500 error this morning and found this thread. Reboot, restore backup and things seem to be working, though the web interface is slow. Guess I'll update. Lesson kind of learned?

After I found my error 500 and reboot/restore, it was slow only for a few mins then it went away

What I noticed was some of my automations were wonky, firing when not supposed to, didn't fire when they should have. I went into each automation and hit update this rule and/or done. The next day, everything seemed to be back on track

Good luck

Yeesh.. that's a lot of rules to do that with. Small price to pay, I guess.

Something to be aware of that has caught me out before, is that when you restore a backup the Mode will become the one that was active when the backup was taken. So if it's the standard overnight backup you use from 3am ish, in most cases that will set the Mode to Night when you restore. That may explain why some rules were not running when they should or vice versa. It will only correct itself when the Mode would next change by time or whatever. The first thing I do after a restore is to make sure I put the mode to the correct one.

5 Likes

Excellent observation regarding the mode, hadn't crossed my mind

However in my case, I don't use modes at all. That being said, someone might benefit from your astuteness :slight_smile:

Rick

1 Like

Yes, as @stephack mentioned, that is @ogiewo’s HTTP driver.

1 Like

Here we go again: The dreaded Error 500.
By looking at my logs, it appears that my database is also screwed up!

Now... which backup do I restore from????
When did this nonsense start????
As the person who started this thread said, this is not acceptable in a consumer product, and should be dealt with on a priority basis by the support team. They've been very good in the past about addressing issues like this, I hope they will continue to do so.
(Yes, I've also sent a note to support, and yes, I've rebooted. I'm just considering when to restore from!)

Restore from you latest backup.
The the backup contains the content of the database, not the database itself. So it will rebuild the databases (clean database) and insert the content that is in your backup into these clean databases

2 Likes

what is device 1045? click the error and see where it takes you.

1 Like

All of a sudden I started to get this again today. No changes to my system all week since I'm on road trip.

I have node-red push a notification to pushover anytime there is an SQL error.

Hubitat Watchdog: app:4175 2019-07-24 19:14:18.872 ML: Kitchen Motion Light ERROR org.h2.jdbc.JdbcSQLException: The database has been closed [90098-197] (offDisable)

I'm not sure why I suddenly got it either.
I'm speculating, maybe it's because when I moved my Hub close to the door (to re-pair a zwave plus door lock), maybe I didn't do a hub shutdown first. Maybe just pulling out the power screwed up the database. (I'm NEVER) doing that again!
I recovered from a backup, and everything seems OK.
Lesson learned: Always shutdown the hub for a graceful end, before moving it!

1 Like

I don't suppose you published that flow, or posted the details in another thread? I just started using node-red to push data INTO HE, it is on my to-do list to setup some flows to pull it out,. Seems like it should be pretty straight forward.

The thread above has a few examples of how to tap into HE websockets and then different ways of using that data. If you simply want to get the raw data and then setup your own customized flows then it's very simple. There are 2 types, event socket and log socket. Just configure a websocket in node for one or both of these.

1 Like

If you want a more targeted flow. You can also setup a tcp in node on a specific port and have HE do a http request to you node red appliance on that port.

Edit:
The above is a little inaccurate. I use the tcp in node to capture data pushed from a WemosD1.

For an http request you would probably be better served using the http in node.