spoil sport
3 Likes
That was my first thought too.
I will also accept a free Pro hub in exchange for correct omniscience. If wrong, I may yield a "My bad", but we'll see.
6 Likes
Maybe. The power output doesn’t seem to match that idea - unless I’m reading the FCC submission incorrectly.
4 Likes
Ok, then they swapped out the existing zigbee module for one that can do thread and zigbee without time slicing then, and it happens to have ble too.
Or none of those things at all. 
6 Likes
Wait a minute wait a minute, I thought the game was we just read the topic title and then we guess without getting any other information! Actually reading the submission kinda feels like cheating...
7 Likes
I’ll need to sell my now redundant C-7 before it becomes a museum piece; it’s been sat gathering dust since the C-8 was purchased at release. Anyone in the UK who'd like to offer me £s, let me know.
C-8 Pro, hmmm:
- No doubt everyone will be screaming for PoE support
- No more issues with Jumbo frames
- Graceful shutdown on removal of power
- More storage for logging. No more picking and choosing the devices/rules where logging is enabled
- An 'ageing' option to set the maximum time logs are stored before being trimmed. 'Keep logs for x days'
- 'Hubitat Dashboard Pro' - you heard it here first. Perhaps someone is currently chained to a desk at Hubitat HQ on an intravenous caffeine drip creating the perfect multi platform local dashboard (remember Grant? lol - it can be achieved)
- Built in MQTT support - bye bye Raspberry Pi
- Official Homekit support - finally approved with the label on the box
The C8-Pro...Hubitat Actually
I can't wait !
Oooh lovely:
It's arrived:
Huh? Is that it?:
Yet of course I'll but it on it's day of release whether I need any of the improvements or not, because
4 Likes
I have (literally) a stack of C7s I need to sell. lol. Join the club.
I've stolen the power adapters for other uses at this point, which is mostly why I haven't bothered trying to sell them. Probably just be paperweights until binned.
I initially intended to set it up to put any LAN integrations on but my current setup doesn’t stress the C-8 so perhaps that would just add a layer of unnecessary complexity
Related to this, it brings me back to my original question on the speed of the hub. I have three hubs in the house but run most of my rules off one - which is a C5. My others are C8s. My original plan was to replace the C5 with one of the C8s and have two hubs - one in the basement and one in the attic. Gives me great coverage. But the issues with zigbee on the C8 caused me to run that one along side the C5 for z-wave only. And since the C5 has the same processor as the C8 I don't think I am missing anything?
The C5 is processing commands fine - but editing rules, debugging etc. is laggy.
10-15 seconds to load the Logs screen
15+ seconds to open a rule
I have about 300 rules. This is what prompted me to ask the question about processing speed moving forward.
Me too, but I just moved all LAN integrations to home assistant instead. I have oodles of CPU/memory in my HA VM to spare, so no loading issues ever. Was simpler, more fool proof, and reliable in the end.
I then bring back what I need to Hubitat via the integration between HA and hubitat.
No guarantee that more CPU/memory dramatically improves that though. I mean it wouldn't hurt, but the root issue could just as easily be a UI optimization issue in how it is loading/displaying all those rules. 
That number of rules is likely an edge case / not their normal expectation, so might be lesser tested than performance with fewer rules. We can't see the internals, so no one can know for sure except staff.
I've never seen a post from staff that any slowness issue was specifically caused by not enough cpu or memory... Doesn't mean it is not true, just pointing that out...
Not trying to be negative - the new hub may/hopefully will be awesome - I'm just a "temper your expectations" guy, in general.
2 Likes
I don't think the dual-stack chips use time slicing, well, at least not in the way some people seem to imply. ZigBee and Thread are both 802.15.4 based. 802.15.4 is the physical layer, it doesn't care what is coming in/out, so long as it's 802.15.4. On the software side of things is where it gets split up.
Think of it like this. 802.11 is WiFi. You're not time-slicing your WiFi transmissions because you're doing HTTP, FTP, UDP, and MQTT all at the same time. That's on the software side of things. Same thing for 802.15.4, but for ZigBee and Thread protocols. Same shared hardware layer, different software layers. The only "time slicing" involved is the same as with 802.11 stuff, if your'e sending a ZigBee packet at a specific instance in time, you can't send a Thread packet at that exact same instant.
So it's "time-sliced" in a way, I suppose. But not really. It's no different than if you have 100% ZigBee stuff. If you're sending a packet to your living room light bulb you can't also be sending a packet to your bedroom light bulb. They have to take turns. Dual stack ZigBee/Thread is exactly the same, they take turns. Whether it's 2 ZigBee devices, 1 of each, or 2 Thread, the result is the same: one 802.15.4 transmission then the next. Just like WiFi. If you're sending an MQTT packet to 1 IP address you can't also be sending an HTTP packet to another. They have to wait. It's not like it's saying "ok, these 100ms I'm doing Thread, and the next 100ms I'm doing ZigBee" or something.
There's no technical reason why the dual-stack chip in the C8 can't just run both Thread and ZigBee. It's designed to do so. Yes, you'll have issues if you have 200 ZigBee devices then try to add 200 Thread devices on top of that. But you'd have exactly the same issue if you had 200 ZigBee devices and tried to add another 200 ZigBee devices. I know the HE devs have said they're not doing Thread on the C8, but they also said they're not doing Matter on C5 and C7, but that's been changed.
Adding a second separate 802.15.4 chip so Thread can have it's own would mean that you never run into issues of a Thread packet being delayed 10ms because it's waiting on a ZigBee packet to transmit, but that might cause more issues than it solves, because now you've got two 802.15.4 transceivers inches away from each other and I'd wager than any benefit you get from having entirely separate chips is eaten up by having the two transceivers interfering with each other. On a dual-stack chip there's no possibility of interference.
Honestly, the only "Pro" feature I want is the ability to write full-on Java code for apps/drivers. With classes. And no limit on what imports it uses. I mean, I can just write whatever I want on a separate computer and run it connected to Maker API, but that involves running and maintaining a separate computer. Release a "Pro" Hubitat with specs around what a Pi 5 8GB has and allow for running JARs. It would dramatically help keep Hubitat on level ground with stuff like HA.
Tho you might need to allow just running Docker images for that, since a lot of stuff HA builds off of is Python only. Or JS. With some sort of built-in container runtime I could make a Hubitat App that runs whatever language I need/want, rather than Groovy (which is honestly pretty terrible to write in, thanks to dynamic typing + nearly non-existent language support in VS Code).
Edit: Going through the FCC listing, there's no mention of a second 802.15.4 chip. The BLE is part of the WiFi chip. If this device will have Thread, it's doing it with a dual-stack chip.
12 Likes
That was also my reading of the FCC listing, and the basis of my previous comment.
4 Likes
Yeah, I saw that after I posted my original statement.
Anyway, we'll see what it has. There is only 4 months left on the confidentiality/non-release timeline on the fcc filing, so there IS a back end on how long we have to wait to see the internals, pics, etc. 
What new features are allowed in thew software/platform is another matter altogether.
We'll see!!!
3 Likes
Considering the number of posts on the Beta forum regarding performance issues, slow-downs, etc... My bet is it being just new CPU/RAM/SSD and not much else. And I'd buy one in a second if it came with Pi 4 - Pi 5 level specs.
As an example, I have 2 'Emporia Vue 2' breaker box meters. They run ESPHome. If I have Home Assistant on an Intel J4125 mini PC (somewhere between a Pi 4 and Pi 5 in speed), I can have all 27 circuits sent to HA every 1.44 seconds and it doesn't break a sweat. If I install the ESPHome app/drivers for Hubitat (which is extremely well written, with almost everything in @CompileStatic annotated functions), it absolutely brings Hubitat to its knees.
Now, there's no real reason to send 27 wattage measurements every 1.44 seconds across my WiFi, other than the fact that there's a GitHub for flashing these Emporia Vue 2 with ESPHome, and it comes with a "Native API" based ESPHome config for them. The pre-made config for these meters also sends 'total daily power', so it's really like 60-70 events every 1.44 seconds. So running that pre-made config with "Native API" on ESPHome, where it sends everything across the wire is definitely the easy way out. I can just flash them and connect it to HA (or HE). Done. Very wasteful of CPU resources, WiFi bandwidth, etc. But easy.
Instead I wrote my own config, using HTTP POSTS to Hubitat, every 5 minutes, with the ESP32 doing a bunch of integrals for giving me kWh updates, and a few more POST hooks set up for instant notification of things like "clothes dryer on/off". This sends at most 1% as much stuff over the WiFi, which is good, and uses vastly less CPU on Hubitat. But really, this shouldn't be necessary. It would be nice to have the "easy" way at least be an option, even if it's a wasteful one.
2 Likes
I'm just hoping the next hub fixes the Iris incompatibility issue. I don't feel like I have an upgrade path because of it.
I put the chances of that at around 0%. Iris v1 doesn't work with the ZigBee radio in the C8. It doesn't work with any currently available ZigBee chips.
You've got plenty of upgrade path thanks to Hub Mesh. Just leave your C5/7 running with just those Iris devices and use Hub Mesh to bring them to a C8 (or C8 Pro).
10 Likes
Thinking about the naming on the FCC filing, I'm even more thinking this being just a RAM/CPU/SSD bump. Bumping the processing power while leaving everything else the same is what I would think of as a "C8 Pro". Otherwise I'd think it would be named C9 or something else entirely.
6 Likes
I get I can do that, but I don't really need two hubs. If I'm still having to run my C7, there's not much point in adding another hub. I'm just trying to be hopeful they can get that compatibility back because I have some devices I just prefer not to lose.
They'd have to use old ZigBee chips, which are also a massive downgrade to anyone else who's not tied down to Iris stuff. If having a ton more CPU/RAM/SSD or whatever the "Pro" brings isn't worth having it as your primary hub with an old C7 running just your Iris stuff through Hub Mesh doesn't make sense to you, then don't buy it?
I probably wouldn't buy the "C8 Pro" if it did support Iris. I want nothing to do with running a non-ZigBee3.0 stack at this point. That would be like having the "C8 Pro" ship with Z-wave 700 inside. It would be nothing but a downgrade to me with zero upside, and for most people, who don't have any Iris stuff, it'd be a downgrade for them too.
6 Likes
