Just thinking about how I might migrate my custom dashboard from HE, if I decide to do so in the future. It’s written in html/css/Javascript and uses local endpoint gets in MakerAPI to send commands to the hub and listens to the eventsocket using Javascript in order to update the dashboard based on hub events. I’m hoping it won’t be too much hassle to migrate. Will there be something like MakerAPI and eventsocket with the CORE?
Like it, no. The whole system is an API, it provides a RESTful API interface as well as a socket.io interface. These are what the UI also talks to.
You will be able to host your static resources (html/css/javascript) for your dashboard on the CORE and then “just” talk to the CORE API directly.
1 Like
Sounds very interesting. Thanks. I love the idea of having Node-RED directly on the same machine and now my dashboards too on the CORE directly would be cool. It will make it much more easy to administer. But I do worry about the work to migrate from how I’m doing it now. Oh well, we will see. It will be a good learning exercise I’m sure!
1 Like
To add another question into this mix…
Would it be recommended to separate the “front-end” from the “brains” in any way, in terms of purchasing a second core hub? I.e. should I use one Core hub for device management / admin / rules / etc and one for dashboards and other display purposes?
Thanks,
Simon
1 Like
You have to ask yourself if you’re going to do any development in the built-in IDE. Then, yes. For sure. Rule of thumb is if you’re going to be using protocols that are going to need a lot of resources, then a second CORE is probably a good idea for the best experience. RTSP streams, development, etc. If you’ve got things that would run better on a separate mesh like bulbs that can repeat and can get powered off and wreak havoc on your mesh. Each situation is unique, for sure. The size of your environment is also a factor. There is no perfect answer to your question. But, should you decide you would like to add a second CORE, your primary CORE will accept it into the family without hesitation. And with a click, they will start working together like they were long lost friends. It’s really that easy.
2 Likes
Thanks @april.brandt . That makes sense, there’s typically no one answer for something like this, it does depend on your setup. I ordered two, I’m sure I’ll have a use for them, maybe more 
2 Likes
awh SNAP! Do I see some development in your future? Or a camper?
What gave it away…my questions on the ide thread about source xontrol…
. The development side has been one of the most interesting parts for me in the Home Automation adventure so far. Very happy to see you have embraced that in Core.
1 Like
We said we were listening…
2 Likes
So no need to mirror devices like for hub mesh?
The Primary CORE brings in the devices from the Secondary CORE. They live on the Secondary CORE, the Secondary CORE acts as a controller. No mirror, no copy.
2 Likes
Totally seamless, very nice. You should make this more prominent, I didn’t see this mentioned anywhere unless I missed it.
2 Likes
We haven’t really had a lot of time to discuss it. There’s so much that it can do, we tried to talk about some of the important things. There is a LOT more that we can do with this. You can also essentially “assimilate” commonly used HUBS to act as a controller for the devices that are still connected to it. We can do this because we are not a HUB. We are CORE.
3 Likes
we are CORE, resistance is futile, you’ll be assimilated…
4 Likes
Ha ha ha I also thought of the Borg when April posted that.
1 Like