Well shucks, that's wayyy flattering! I have a version of Reactor that works with Hubitat and other platforms (all at the same time). That's been my focus for a while. I also wrote/maintain a Venstar ColorTouch Thermostat driver for HE, because it looked like the previous developer/driver had gone inactive (he now seems to be back, so I guess there will be two). So I'm lurking, and I read here quite a bit, if not posting.
FWIW, Reactor uses MakerAPI and the (basically undocumented) eventsocket feed for its Hubitat interface. This Reactor has a dashboard, but it's primitive and not the focus of my project; I'm more focused on the rules engine side of things (a simpler alternative to NodeRed, basically).
I think it's the undocumented-ness that throws people off the trail (heck, I'm not even 100% certain what @toggledbits calls eventSocket{} is or isn't identical to what I call eventStream.)
See the Interface Docs for what we currently know on that and other protocols.
If more is needed, perhaps approach @support_team for guidance.
Yeah, it's a bit confusing. Here's how I have interpreted it:
I think the (documented) eventStream interface is for a device driver running on the HE that wants to receive streamed events from a remote endpoint.
I think that's different from the stream of device changes published by the HE on a websocket you can open ws://your-he-ip/eventsocket which is mentioned in several other forum posts, many quite old, but as far as I've ever seen, is otherwise undocumented. This is for remote services running elsewhere/off the hub (like a dashboard running in your browser) to get a feed of device and hub changes (and if the folklore is true, this is what their own dashboard uses to update its widgets).
Note to anyone trying the websocket URL above: if you have Hub Login enabled, you won't get events until there has been a login at the UI.
@toggeledbits has a well considered approach to his implementations and enhancements that I admire even though I have some extra features I would like in HE. This is critically important in multi controller support
So a couple have mentioned multi hubs. Are these hubs both local? I’m assuming they don’t communicate? I’m sorry I’m not familiar with this situation but if it just requires multi connections it’s doable but something I need to implement quickly to achieve. I will give it some thought.
I agree with others @toggledbits has been very helpful and great. The community as a whole seems that way. I have not done an open contribution to anything since the days of SageTV (did a lot of work over there) due to time. It’s nice to see an active community and more importantly have some time to do this. I’ve had this hub for several years (a version 1 and now 2) and have always loved it.
Expand/Resize Tiles by clicking and dragging corners like every other OS in the world
Yup something like this is on the list. Clicking holding/moving around etc (doable not sure yet not to UI portion)
Long Press to enter tile options
Not sure on this my initial thought is not a bad idea, but my initial plan was all editing and such would be done in a wizard like setup, so think on this one, I will (in my yoda voice)
Easy Camera Feeds (maybe some magic on the backend, I dont know if this is possible, Im dumb)
Camers via certain types is upmost important to me and a tricky one but I just started work on that backend (Reactnative is limited especially on the IOS side)
Those the ideas I didn't disagree with much thanks!
Yes, both local on the LAN. The hubs can connect to each other using TCP, that's called "Hub Mesh"
So they connect but they don't share devices correct? Like you would need to query multiple devices. I am just trying to grasp how this works since I don't have multiple.
Correct, devices are only shared, when marked as such on the device page(hub mesh option activated) -and- on the secondary hub, that shared device is , I'll say, imported.
Edit- On the hub where the device is shared to, a type of virtual device(Hub mesh device) is created to mirror the actual device. The virtual device will then see all the events from the actual device, and the virtual device can control the physical device
So my guess is you guys are wanting a use case where devices are not imported so you can import from both hubs. I am sure there are reasons for having to hubs in a single location...Its easy enough to add support to query more than one so I did.
Once a new (hub-based) Dashboard App arrives on the scene and gains traction in the community, who decides whether it gets included in the Built-In Apps section? Currently, I see entries like SharpTools, ActionTiles, and even Smartly listed in "Built In Apps" and wonder how such distinctions got made. Some of these are commercial products, obviously.
A few minor players (Virtual Keypad, Switch Dashboard, etc.), all community apps, appear in HPM. While some (commercial) heavy hitters like Hubivue, Home Remote and HousePanel, since they interact with the hub via Maker API and thus lack an on-hub component, are only mentioned/listed in the Forum.
Putting it another way, how does an app developer apply for inclusion ... is there a formal process, or were certain early adopters grandfathered in somehow?
None of that really applies to an app like this as it won’t need an add on install on the hub (unless I hit some wall with function I don’t see hitting)
