[Wiki] HTTP Features and Endpoints

Interesting. Just as one example, on the list of Compatible Devices, the driver listed for the Aeotec Recessed Door Sensor 7 lists a driver (Recessed Door Sensor 7) that has not been available for about a year. I inquired in the forum when it became “Deprecated”, and was told by Mike Maxwell Bobby Dobrescu that the driver had been superseded by the Aeotec Door/Window Sensor 7 Series driver. I edited an appropriate change to correct the Documentation, the change was never approved, and eventually disappeared. It’s still wrong, a year later.

I no longer suggest any changes because it’s not worthwhile to waste my time trying to improve the documentation. The courtesy of an explanation why the changes were rejected would have been nice.

1 Like

Changes are not approved in the sense that your edit is going to be added verbatim. They are incorporated through our own editing process. Most posted changes are not in the same style, or wording. So they are rewritten. Unfortunately, there is no feedback mechanism available to us when we do this.

As for this particular change, I will pass it on.


My suggested wording in this instance had the exact same wording and style in the driver column as is now (correctly) shown for the Aeotec Door/Window Sensor 7, which uses the same driver. It wasn’t a major editorial change.

Apologies for this. Looked back in the rejected list and saw there was no reason it should not have been approved as it was submitted. It was a mistake to reject the change, as it could have been added directly.

The way the wiki contributions work right now isn't great. This is how it's presented, with no option for feedback.

[Approve Approve all . . Reject Reject all] . . [Mark as spammer]

In this particular instance Approve was the correct choice and it wasn't selected. Sorry about that. Discouraging contributions to the Wiki is certainly not the intention and we will introduce some changes to help improve this.

Often users will submit, but won't list the same names they use in the forum, so attribution isn't possible in those cases. That wasn't the case this time and your correction has been made. Thanks for submitting it and helping to improve the Compatible Devices List.


Thanks. I wasn’t looking for attribution, just trying to help improve the documentation.


From another thread these will let you adjust the #of events for your devices as well as the the state history size

I just tried these commands and I get an error 404 back and the value doesn't change.
Am I missing something or does this no longer work?

I got the same error when i initially tried those endpoints, but i tried in a few browsers and eventually they took properly. Not quite sure why or how i got it to work, but it did at some point..
Depending on how many devices you have, it may take a bit to complete (when you dont get the 404 error), so make sure to keep that tab open until it completes processing and gives you an output status message.

Thanks for the advice. I get the error almost immediately. Will try different browsers and see what happens.

EDIT: I was using chrome. Tried incognito mode and Firefox. Still no joy. :thinking:

I think I may have done a reboot on the hub and then tried those endpoints after everything came online.

I use regular old chrome. Are you on a recent firmware? This was a recent addition and setting state history size very recent.

You are prefixing the commands with the hub's IP Address, right? :crazy_face:

1 Like

Worth asking but yes I am.

Yes. All my hubs are up to date and this is happening on all of them.

Looks like you accidentally dropped the /hub/ at the beginning of the command.


I assumed the 'hub' was to be replaced with the IP address. :blush:


Good catch!


according to @thebearmay
"Finally, there’s a small button underneath the hub that will force a reset of the DHCP settings on the hub (after which reboot the hub and try the find actions again.)"

Hasn’t been a hidden feature for a while:

The button itself is pretty well hidden though :wink:.


Very Helpful!


How about the NTP endpoints, are they worthwile adding to the list?

There is no DHCP setting for NTP, true, but we got these endpoints (since 2.2.4):

http://hubitat.local/hub/advanced/scanForNtpServers - scans local network for NTP servers and shows the list.
http://hubitat.local/hub/advanced/ntpServer - shows current NTP server
http://hubitat.local/hub/advanced/ntpServer/<-value-> - sets NTP server


Going through the available commands i found that the following are stale (error 404)