Is it normal to see 500,000+ for state size when looking up device stats? It caught my attention because I was troubleshooting my hub crashing from the latest platform updates.
I'm running 0.4.59 currently.
I assume this is because the main network device has the entire volume of war and peace loaded into the 'alarms' field.
I did just hit archive alarms and now state size is down to 6k. I'm not sure, but I'm wondering if maybe somehow the latest versions of the platform can't handle the 500,000 state size and it causes it to crash.
I am not sure what maximums the Hubitat has (it may vary by hub even) but the Alarms stuff CAN build up quite a bit if it is not archived. It also depends on what your Unifi system is set to retain for Alarms. I have never seen one that large... but if it had been sitting and collecting for quite some time and not archived before now I suppose it is possible. Since it stores things like if a device goes offline and comes back (as simple as power or even telling it to restart) as well as many other forms of events.
Some of the Unifi API stuff can just provide massive amounts of data. The problem is that even with those massive amounts there are usually some small pieces that ARE desirable so you have to get the whole thing because there is no way to get those valuable nuggets otherwise. Alarms thankfully are something that can be treated as an on/off item (thus why you can disable it).
Not sure if it would be better to disable it by default (I cannot remember anyone else having so much it crashed their system). But I will certainly keep it in mind. Your system is operating "normally" now that it is disabled, correct?
I scored one of the new UXG-MAX gateways -- Gateway Max - Ubiquiti Store @snell If there is any info you would like so that you can add it to your driver. It should behave like all the other UXG hosts,
If you can shoot me what the Model is listed in the State Variables of the child device, I can get it added to the device recognition. It looks like it could use the UXG child driver but I will need to tweak that to allow for the additional ports that it has available rather than make a whole new driver.
Added recognition for the UXG Max. It should also trigger a slight addition to the UXG child device default values (added ports) when a Max is created. To see this effect on an existing device you would need to delete the existing child device and let it be recreated (probably not worth it as the fields will eventually populate with data anyways).
Was the generic one already there or did it also get freshly generated? It will never remove a child device automatically unless you are removing the parent.
Ah, ok then. You can delete that child device then and see how the UXGB continues to work for a while. I was worried I somehow made it create a second device somehow.
At this time, no, I do not know of a way to have them in a Rule (as the parent driver is now).
The child drivers DO have an attribute for port map however the main driver posts the information as a State. So it is visible within the State Variables section of the device(s) if someone needs to manually check it, but for Rules to use something it must be an attribute and posted as an Event (so it shows in the Current States).
I was hesitant to post them as Events because it would pile even MORE information into what are already event/data heavy devices and there had been no requests (until now) for the data within them to be used by a Rule.
It WOULD be relatively easy to change... but I would definitely want to make sure it is not going to cause trouble. Up for being a guinea pig for a bit?
OK. It didn't seem to be possible, but I thought it was worth asking. I have a link that occasionally drops from GE to FE. I was thinking I might be able to use a Rule to monitor.
Well, I am testing having the port map appear as an event on my system. It only required changing one line of code (one benefit to how I have things) although I did similar things for some other maps. I will see how it seems to impact my system and decide if I will make it a "standard" thing going forward.
It is weird for something to change what it is operating at though... Does it seem like a Ubiquiti issue or the client? Just curious.
My keystones have been MOST of the networking problems I have had... but I have one cable that I ran a huge way through walls, ceiling joists... tested out fine... but once all the drywall, shelving, and everything else was put in place SOMETHING must have punctured it because it is DEAD... multiple wires fail. One of multiple (I think 4, maybe 6, but I ended up needing a switch anyways) cables I ran through there. So frustrating.
Hello all. I really like the sounds of this app but have run into a problem. After downloading, installing, etc per the guide I can’t get logged in. I repeatedly get a “no cookie, please log in again.” It’s probably something basic on my end I’ve overlooked. If anyone can help out, I’d really appreciate it!
TIA.
Do you have two factor authentication enabled on your controller ? If so, you will have to create a second login that does NOT use 2FA. Then use that login in the Hubitat APP.
