This is super cool and something I would never have though of, I wonder how hard it would be to implement on a system built from the ground up:
I don’t normally comment here as you all have realized, but…
Our UI is completely decoupled from the backend and based on React, which has support for Accessibility built-in. Adapting the UI to make sure we are mostly compliant won’t be a major issue and is part of our road map. We probably won’t be fully compliant on initial release, but we will get there, probably will need some feedback from users to get all the way once we have our Cores out in the wild.
9 Likes
CHIP / Thread ?
Thread, yes. CHIP, when the time is right.
3 Likes
Does CHIP use specific radio hardware or is it “normal” WiFi?
1 Like
Will there be a mobile app for notifications and geolocation?
Might we get smart notifications allowing for decision/branching one day?
6 Likes
Project CHIP is now rebranded as Matter. It is IP-based connectivity via ethernet, WiFi, and Thread, with Bluetooth Low Energy used for easier initial setup. Thread runs on the same chip as Zigbee but with a different firmware. It does however require a modern Zigbee chip like the one in CORE.
5 Likes
There will be, but probably not at launch.
This is definitely on the roadmap.
5 Likes
If there will not be an in-house geofencing/presence system at launch, will there be any third party support from places like Life360 or presence detection via local network IP?
yes, there will be. Details will be published soon.
4 Likes
Will it possible to use Matter and “old” zigbee at the same time on the same chip?
1 Like
While this is technically possible we’re still not sure this will be a good idea, not until there’s a variety of Matter over Thread (or however the naming of this is supposed to be used) devices to use and test with together with a sizeable ZB3.0 mesh we will know for sure. Our current standpoint is that it will require two CORE, since they integrate seamlessly it is not an administrative burden, just a matter of potential extra cost.
Matter over WiFi/ethernet is another matter (pun intended), that has nothing to do with the multiprotocol chip running Zigbee/Thread.
3 Likes
Ok, then the conclusion for now is, if I use zigbee/zwave/WiFi/LAN for existing devices and want to add extra devices on Matter, threat, CHIP or whatever, I probably need an extra CORE?
As it stands right now, unfortunately yes. Fortunately there’s more you can do with an extra CORE, so it wouldn’t be “just” to run both Zigbee and Thread at the same time.
3 Likes
-Notification (Email or Phone text)
- API Maker
-Motion Lighting App
-Lock Code Manager
-Button Controller App (Including multifunction pads (ex: Aeotec quad)
-Mode Manager
-Device Firmware updating
-Security modes -Away, Home, Night, Disarm
-Calendar integration
-Device replacement without losing it’s attached apps and dashboards.
Oh you won’t need all of these apps. Everything will be able to be very easily done within the logic engine. We will make it easier for you by creating templates for such things.
I know you’re speaking comparatively to what you know, but CORE is definitely a different way of thinking.
I will leave these questions for @markus for later.
Device firmware updates
Calendar integration
Device replacement
5 Likes
The libraries used on CORE for Zigbee and Z-wave support this feature. Which devices we will support this for at launch is yet to be confirmed.
These types of integrations tend to be very much floating targets and would fit better as a 3rd party integration.
That is an integral part of the design. There will be a Replace function built-in.
4 Likes
I’d like to expand / add to my earlier post with some random examples of what I had in mind, based on what I have been setting up recently on my HE hub and some ideas for the future…
The list below outlines my personal solutions and is by no means complete. I’m not suggesting these are the way I would like these features implemented on Core, I’m more interested to see similar outcomes, but the methods used can vary. At the moment I am more focused on the monitoring elements, i.e. the ability to see the status of the elements listed. I will eventually move on to alerting, warning me of issues across my setup when they come up.
Network Health
- WiFi channels for 2.4 and 5G using a rpi CRON job
- Zigbee channels using HE Community drivers for Hub Info and DeCONZ
- Internet connection status (Up / Down) using result from Web (HTTP) calls
- Future: Speeds of local and Internet comm’s, Zigbee mesh stats, device comm’s speed
Key HA Devices (Hubs)
- Hub presence using HE Community drivers producing virtual presence sensor devices per hub based on PING result, including my Bond hub, raspberry pi, SensorPush Gateway, EcoWitt Gateway, mobile phone, tablets, etc.
Hub Health and Key Services
- Availability of Grafana Web Interface using CRON job
- RPI CPU (?) temperature using CRON Job
- Future: Status of following services: InfluxDB, Grafana, Conbee2
- Future: Database sizes, disk usage, success / fail of various backups, etc
Simon
While we can answer each and every one separately, it really boils down to the fact that some tests and checks are built in. Some checks should be left as 3rd party drivers and others are built in drivers. All are possible and easy to implement on CORE.
Device Health is a built-in feature of CORE. State is a combination of different device statuses. Among them, Device Health. I’ve attached some screen shots of State. Log level is not relevant in this case.
I’m surprised you haven’t pulled this info from our campaign. All is touched on there.
4 Likes
I must have been dazzled by all the other great features we can look forward to… 
2 Likes