This has been suggested before. I think it's one of the easiest and most valuable changes to implement. For example, I use a lot of energy monitoring automations. Energy monitoring devices generate a lot of events. I capture them already in an external database, so I don't need the hub to do it.
It would be great if they could add a "storeEvent" parameter to sendEvent so developers who write apps and drivers can have control over that. I know of several drivers that use attributes to display information on internal housekeeping tasks. There's no reason for that data to be stored, but it is.
Event logs are pruned once every 24 hours (at 2AM) to the last 1000 events per attribute attribute per device from what I've read. The other logs (not event logs) are not written to the DB, they're just a file from what I've read in this forum. If this is wrong, please correct me.
EDIT: Some sources:
The above is corrected in a post below. I should have read further in that thread.
@mike.maxwell could you clarify? Should there be 1000 events per device maximum? Or is it 1000 events per device event type (so 1000 temperature, 1000 contact, 1000 battery).
Would you consider making that something that's settable by the end user?
I certainly don't need to see 100's of pages of events for devices. I'd imagine it's much worse for some devices that log many event types!
Allowing 0 - 1000 with 0 being no event logging and 1000 being the default maximum would suit most users and might help immensely with database corruption, flash wear, possible slow downs, etc?
The quantity of events are kept in history has nothing to do with database corruption or flash wear. A database is damaged by writing (deletion is a write operation).. Write cycles directly impact the longevity of flash.. So it's logical that having the appropriate tools available to limit what is actually written to the database is the better course of action.
That's part of what I suggested .... by setting it to 0 there would be no event logging at all. While anything non-zero (X) allows event logging and prunes to X during whatever maintenance they do overnight as usual.
That seems to be a reasonably quick thing to implement, anything else (different database, per-event-type limits, per-device limits, etc) I would imagine would likely be a bigger job!
I keep my hubs on an UPS in the event of a brown out/power loss, but I definitely see the need for some sort of battery dock which could act as both a backup and a means to move the hub for device pairing. I was forced to move my hub to be able to pair my Zwave locks and Dome Shut off Valve (both of which were already installed). Luckily had a super long Ethernet cable and power near by to power the hub.
With regards to what a pro hub could allow, definitely stronger Antennas would go a long way and also solving the so-called "bad repeaters" (i.e. Lightify) which do not work with other ZigBee devices. These "bad repeaters" worked fine with Wink and only became problematic with HE which forced me to by a 2nd hub and use HubConnect.
Other than the above issues (and the clunky interface), I'm pretty happy.
I'm not so sure about "Stronger Antennas". I always say we should state our requirements in functional terms and this may be another case where we need to think about functionality. I think we want the wireless protocols to be "better" (more reliable being the primary attribute). I'm not sure we want stronger radios (if that's what is meant by stronger antennas). Years ago I would have said that's what I wanted in a WiFi Access Point (or Router). Living in a metropolitan area, strong WiFi is a curse. My Unifi is telling me it is picking up 17 access points right now. What would make my Wifi better (and my neighbor's too) would be better tools to tune the radio strength and propagation patterns to cover my home (and perhaps my yard) with minimal infringement on my neighbor's home (or yard). Those sound similar but they are very different deliverables.
Having some way to build the better mesh using empirical data rather than guesswork might go a long way to making the wireless protocols more reliable.
Agreed. Stronger radios in a low powered mesh network makes no sense at all. A high powered radio to reach the far edges of a mesh is useless if the device can't answer back.
Why is HE a hardware product at all? If it was also sold as software or SaaS that runs on commodity x86 or arm SBCs with a Z-stick attached, wouldn't that make it a more easy product to sell and support? Then folks could scale it as needed, different form factors, power/heat requirement etc. Is there something special and unique about the C-x device? I can think of docker, raspberry pi, intel NUC as being some target platforms. Heck even an image that would run on a VM/vps in the cloud could be interesting.
That is what I would love to see. And there are certainly other products that do it that way...
Although I can't see either company's books, I would guess the other company I'm thinking of has much higher profit margins than Hubitat because of it, too...
But I certainly am not trying to be disrespectful. Hubitat has every right to run their company how they want. And I hope they are super successful.
As much as I would love a roll your own option, and would gladly pay the $70 cost of another hub just to be able to do so. I understand the devs standpoint.. If they begin selling the software not only will they be undercutting their hardware sales, it will only be a matter of time before someone releases the software to all of the "warez" and torrent sites.
and if software giants like microsoft and adobe cant protect their software what chance do the hubitat devs have? Even Denuvo the platinum in gaming protection is constantly being defeated, many times on day 0
There’s competitors doing this. I wasn’t successful in finding a free license to do that. Besides it would break any cloud intergration since the license ties to one server. I can’t see how two servers can check in at the same time and the cloud intergration knowing which server to communicate with.
In any case, the slow downs, database corruption, and constant rebooting needs to be addressed.
