With field tests I pictured us, enthousiasts, buying it, working with it for some time, finding and reporting bugs, just sort of similar to the beta period with the pro 23.
No clue.
Doesn’t sound too appealing, spreading out over two devices increases the probability of failure. If you could run self-hosted with it’s own Zigbee antennas, it would be a different story.
My guess would be that it will require at least a Homey Bridge as “external antenna provider”, since providing support for BYO Zigbee/Z-Wave/Thread will require too much work, and will also be a support nightmare.
That said, perhaps the “Zoney” device that @smarthomesven found out about is a possible Bridge replacement? Since the Bridge is using rather outdated radio chips.
2 Likes
Or let Zigbee be handled in a way like Zigbee2MQTT, so with an app on Homey…
I notice aeotec, their z-stick zwave stick is compatible and possible to add it as a device. So they could be added and supported through apps.
That Z-Stick looks like a simple router (extender), it likely isn’t related to SHS. But it might be that support for external USB devices is added to the Apps SDK later
I’m with @robertklep on that, can hardly believe Athom will support any and every user connecting their own devices, and expecting it to work, that’ll be driver hell!
There’s enough platforms out there that do that, and people wanting such functionality are not the ones willing to spend much money on it, do remember Athom is a business.
I wouldn’t be surprised if this is going to be their business/enterprise solution. Put the self-hosted server (which is probably going to be subscription-based?) on some rack server and then put Homey Bridges (or some replacement that supports ethernet) on various floors and you can roll out Homey for automations in a business.
They’d probably sell it to enthusiasts as well, but going enterprise is a common path for companies that are in consumer markets that are hard to grow because they require expertise and/or consumer markets that get commoditized. Most consumers do not want to learn how to use a smart hub like Homey or HA and certainly don’t want to spend 399 Euro on it. I think for the non-prosumer market, the writing is on the wall, Apple TV, HomePod, Google TV Streamer, etc. are Thread border routers and once Thread + Matter devices roll out en masse (IKEA just started), that’s what people will use. On the other hand, consumer thread border routers like the HomePod are not really fit for businesses + larger businesses do have or will hire the expertise to set up more complex systems.
The Homey SHS will be a subscription service, yes. But there will also be a lifetime subscription. I couldn’t find anything else about the subscriptions in the web app code. In the mobile app, there are no references to it at all (I decompiled it)
1 Like
I doubt if Homey is ready to act as an enterprise solution, though.
But connecting bridges (or like hardware) seems logical.
Or they could support just one or a few third-party dongles. Or even develop their own dongle, like they did with the Energy Dongle.
If it would support Bridges, then there should be a reference to it in the Mobile app, since only the app can connect a Bridge in satellite mode. But I can’t find any references to the SHS at all when decompiling the mobile app. But it might be added later
The Zoney device almost certainly isn’t any replacement for the Bridge. It does show the Bridge setup, but that’s because it’s copied from the Bridge. I can clearly see in the code that it loads the same animations as the Bridge setup normally does.
And there’s a reason why they did that. All of the ESP32-based devices (Bridge and Energy Dongle) use the same OTA server (ota.homeybridge.net) and the same broker.homeybridge.net server for communicating with Homey Cloud and checking if it’s a genuine device (see this post). These are parts of the strings in the Homey Energy Dongle firmware file obtained from usb.homey.app:
0123456789abcdef E (%lu) %s: Failed to get peer name: %d (%d)
X-Homey-Bridge-Host Broker E (%lu) %s: Incoming host name is too long: %s
X-Homey-Bridge-Port X-Homey-Bridge-TLS X-Homey-ID E (%lu) %s: Incoming homey id is too long: %s
I (%lu) %s: HTTP_EVENT_ERROR
I (%lu) %s: HTTP_EVENT_ON_CONNECTED
I (%lu) %s: HTTP_EVENT_HEADER_SENT
I (%lu) %s: HTTP_EVENT_ON_DATA, len=%d
I (%lu) %s: HTTP_EVENT_ON_FINISH
I (%lu) %s: HTTP_EVENT_DISCONNECTED
https://broker.homeybridge.net/v1/info I (%lu) %s: Request to %s
E (%lu) %s: Failed to initialise HTTP client
GetInfo E (%lu) %s: %s(%d): Failed to set header X-Homey-Bridge-Build: 0x%04x
E (%lu) %s: %s(%d): Failed to set header X-Homey-Bridge-Serial: 0x%04x
E (%lu) %s: %s(%d): esp_http_client_open failed: 0x%04x
I (%lu) %s: HTTP GET Status = %d
InitInput GPIO E (%lu) %s: %s(%d): gpio_config failed: 0x%04x
E (%lu) %s: %s(%d): gpio_isr_handler_add failed: 0x%04x
Internal error %02x:%02x:%02x:%02x:%02x:%02x commands restart get_mac get_serial_hash get_version minimum_free largest_free_block Batch fusing not enabled Failed to disable JTAG Failed to disable ROM printing Failed to commit fuses I (%lu) %s: Assigning MAC: %s
%2hhx:%2hhx:%2hhx:%2hhx:%2hhx:%2hhx Invalid or missing MAC address Invalid MAC address E (%lu) %s: Failed to generate serial: 0x%04x
random_part E (%lu) %s: Failed to begin batch: 0x%04x
Missing hex or color Invalid hex Invalid hex length %02hhx%02hhx%02hhx Invalid hex format enabled Invalid or missing 'enabled' field get_serial dump_ram_log logging fuse_begin_batch generate_serial assign_mac commit_fuses_and_lock set_led erase_homey_cache get_free_memory HyEnergyDongle E (%lu) %s: %s(%d): Failed to initialize DSMR
E (%lu) %s: %s(%d): Failed to register EnergyDongle commands
E (%lu) %s: %s(%d): Failed to register EnergyDongle factory commands
E (%lu) %s: %s(%d): Failed to initialize EnergyDongle WS
I (%lu) %s: Got Homey information from cache:
I (%lu) %s: - Host: %s
I (%lu) %s: - Port: %d
I (%lu) %s: - Homey id: %s
I (%lu) %s: - TLS: %d
I (%lu) %s: Broker failed to get Homey information: 0x%04x
E (%lu) %s: Invalid serial!
W (%lu) %s: Not linked to a Homey
I (%lu) %s: Got Homey information from broker:
I (%lu) %s: - Host: %s (old: %s)
I (%lu) %s: - Port: %d (old: %d)
I (%lu) %s: - Homey id: %s (old: %s)
I (%lu) %s: - TLS: %d (old: %d)
W (%lu) %s: Failed to cache Homey information: 0x%04x
I (%lu) %s: Retrying state %s in %lu seconds
I (%lu) %s: Connect backoff: %lus
I (%lu) %s: Connected to Homey after %lu attempts
I (%lu) %s: Failed to connect to Homey (attempt: %lu)
E (%lu) %s: Failed to connect to WiFi: 0x%04x
E (%lu) %s: Transport failed: 0x%04x
E (%lu) %s: Ping watchdog triggered
W (%lu) %s: Failed to close transport: 0x%04x
E (%lu) %s: In stopped state
I (%lu) %s: Boot ID: %08lx
E (%lu) %s: Unexpected event bits: %lu
I (%lu) %s: State change: %s -> %s
E (%lu) %s: State failed: %s, error: 0x%04x
X-Homey-Bridge-Build sOnHttpClientInit E (%lu) %s: %s(%d): Failed to set header X-Homey-Build: 0x%04x
X-Homey-Bridge-Version E (%lu) %s: %s(%d): Failed to set header X-Homey-Bridge-Version: 0x%04x
X-Homey-Bridge-Serial E (%lu) %s: %s(%d): Failed to set header X-Homey-Serial: 0x%04x
I (%lu) %s: HTTP_EVENT_ON_HEADER, key=%s, value=%s
X-Homey-Bridge-Force-Update X-Homey-Bridge-Update-Available E (%lu) %s: Failed to start OTA Task
E (%lu) %s: Failed to get OTA state: 0x%04x
E (%lu) %s: Failed to boot after OTA: 0x%04x
I (%lu) %s: Boot success after OTA
E (%lu) %s: Failed to abort OTA process: 0x%04x
Begin https://ota.homeybridge.net/v2 I (%lu) %s: Request: %s
I (%lu) %s: No new firmware found
You see it uses homeybridge.net, which the Bridge also uses. The Zoney likely also works the same way, so that’s why they copied the Homey Bridge setup (for testing). I couldn’t find anything else about the Zoney in the mobile app except for the Bluetooth advertisement it expeects (which is how I got the mobile app to show the setup wizard, by cloning and advertising it from another device) and the setup process. I think it was some kind of internal test by Athom that was accidentally left in the production builds of the app.
Anything short of providing the ability to add external radios is a total waste of time
I think they might use the Homey Bridge as an external radio, or that they will allow USB-based dongles. But I couldn’t find any references in the code about external radios. It likely will be supported somehow, as in the Homey Developer Tools code, you can see that it doesn’t hide the ZigBee, Z-wave, IR and RF tabs. The only tab it hides is LED Ring, which is obvious
I hope the Sonoff Dongle Max can be supported in some way.
Supports PoE, so no need to be close to the host device.
It uses Ethernet? That sounds more like a bridge to me (like Philips Hue bridge). Can you link it with the eWeLink app on your phone? Then you can add it with the eWeLink app for Homey if your ZigBee devices are also eWeLink
It’s a dual antenna router (Zigbee OR Thread), not a hub.
I don’t think you can use it with any current Homey devices, but you can use it with Home Assistant using ZHA.
What’s the point of self-hosted then, wouldn’t they rather sell units than people running Homey on their own hardware? Though maybe subscription fees are more attractive than people buying a device every 5-8 year. OTOH, that doesn’t really gel with them going to possibly offer a lifetime purchase.
I guess we’ll see 
.
The code where the lifetime subscription is mentioned is in this post
Here you can see a function to transfer a “lifetime subscription“. But you also see messages about subscription being expired, so I think they will offer both a recurring and a lifetime subscription.
It’s a Zigbee coordinator/Thread leader right? Not just a router.
