Feature Request: API Enhancements

@Will_Price,

Definitely looking forward to 6.0. It sounds like a promising alternative. From your description it sounds like you would intend that the basic commands (pause, play, mute, volume, channel, etc.) would be hard button only with no need to look at the UI. Do I understand that right? If so, definitely on the right track.

I have spoken with some friends with experience about the piece of hardware I described. Similar feedback you gave - I need to be prepared to drop $50k - $100k to get through design and prototype for something that is decent and can be manufactured. Obviously I’d have to look at this as a business and not a hobby effort. No specific desire to do this, but there may be a market.

I think the only issue with the game controller is WAF. Women aren’t likely going to find that very appealing. I don’t do this for a living, but I try to make my system usable by my wife and guests to the extent that they can “just use it” without much learning curve. For example, I have a guest room with a TV in the room and that’s it. All of the sources are in a central media closet and the guest room TV is connected via a HDMI matrix switch. I wouldn’t want to explain Simple Control or a game controller to a guest. For now I just limit them to watching DirevcTV and they have a DirecTV remote. But with a more integrated remote they could watch Roku, AppleTV, BRD, PC, etc. I think any consumer home automation product has to consider things like this to make adoption as wide as possible.

I am not a Control4 fan since they are so into vendor lock-in and custom programming, but they do have a nice remote. Though I think they went too far. Get rid of the LCD screen. Not needed. That’s what the app should be for and this is where Simple Control wins big. I’d also kill some of the buttons, but in general it is pretty streamlined, in the right shape, passable ergonomics, and a familiar form factor to non-technical people / people unfamiliar with the system.

In any case, it sounds like you guys are thinking about it, and I look forward to the coming development. And, yeah, it would still be great to see API enhancements for more technical folks like me.

Thank you.

Now that we have the harmony integration not sure why RR has to bring out a hard remote ? Am I missing something. I would rather have RR invest more time and efforts in improving automation routines. I use ISY a lot for programming it will be nice to similar features in RR. For instance if a certain thing happens send an email and text messages, repeat the same until the alter is removed/reset

So, can you tell me how the integration works? Do I basically need to have all my devices and all my activities set up in Harmony in addition to Roomie? I agree this would work, but isn’t ideal. I think @Will_Price has ruled out any development activity on a hard button remote. I get that. That is a big capital investment. I would still argue that exposing the APIs I have previously mentioned in several threads would be a low effort value-add that people would be free to use if it made sense for them.

I guess the intended use is to sync the activities using the same name so if you press say watch tv, it will execute watch tv on harmony and will set the remote interface buttons etc to tv compatible buttons…however in my case watch tv activity in RR does a lot of other things like say lights set-up etc…so the action items are not the same, so I ended up adding harmony activity as a next sequence step in the RR activity…just say add existing device, select the hub, the add command activity then select the corresponding harmony activity.

I guess I am going to have to buy one and experiment. Maybe it is the solution to all my (first world) problems!

So I would just note that while at some point there probably will be API enhancements . . .

@Will_Price, any update on when this might be on the roadmap?

In the context of this old thread, that already happened. The original request was: “I’d like to be able to control the current activity by sending it generic commands like play / pause / mute and have Simple Control translate these to the appropriate device commands”.

APIs to do exactly that were subsequently released as part of our Siri Shortcuts API. UI even exists for them in the Rooms editor for each room.

The new controller support for hard buttons did also subsequently get released in V6 and then enhanced again in V6.5. Unknown at the time of this thread, we then added Harmony Hardbutton integration greatly enhancing the hard button possibilities.

We did many times more things than discussed here in this area. If you’re specifically and only looking for a custom HTTP API, that’s an extremely specialized need (party of one?) that is difficult to prioritize since I’m not aware of anyone else needing that. To the extent we upgrade the HTTP API in the future, which remains something we would probably do one day, this may occur simply because it is a logical extension. That currently has no priority, so something would have to change for that to happen. For instance, if the systems that utilize our API (mainly SmartThings) needed more or changed APIs, that might precipitate it. Or, evidence of broader user need.

Thanks for the update and explaining this is a lower priority. It’s helpful just to know your thinking.

I guess the confusing part for me is this capability is already exposed to support the Alexa skill. Not sure why it would be difficult to expose that to the users, possibly with an altered contract. If it is just a preference thing - for example, maintaining control over the Roomie ecosystem - then it makes sense as it’s your product and your choice. Just seems like an easy win even if I am the only one regularly asking. I probably represent some X number of possible customers who want this feature, but aren’t asking.

I am back to posting since I have time to focus on this again. Next step is to experiment with Harmony as that seems like the best possible solution amongst the available choices. I am sure I will be here with questions. Thanks again.

Have you tried the new eisy with polyglot nodes? Do they work ? I cannot make it work in RR but they all work fine on eisy. BTW the API you developed for isy, is that shareable?

Which API? Do you mean how I have ISY sending commands to Roomie from my mini remotes?

Let me reframe my question, l have third party polygot nodes in eisy, like the Philips hue and harmony Remote, this enables to have all devices in one platform along with my Insteon devices…when I link the eisy to RR all Insteon devices work but third party devices added via polygot nodes doesn’t work…is there a way to make them work?

I see. Probably a question for Will and whether or not the behavior of Roomie needs to be modified to see the polyglot nodes the way it sees the original ISY nodes. I actually had to remove ISY from Roomie about a year ago after troubleshooting with UDI and found that Roomie was constantly polling the ISY which caused the ISY to drop packets. Honestly, the ISY should flake out over something like that, so don’t really blame Roomie. But I never opened a ticket either. Maybe there is some update work that could be done to the ISY integration since there have been numerous ISY changes over the last few years.

The problem with ISY has always been that it doesn’t notify us of anything. So it’s polling or nothing. By contrast, Lutron has a beautiful system that is perfectly efficient at notification so there’s no polling whatsoever.

The ISY people have not notified us of any changes so if there’s something new, they should do so.

However, those things you mentioned like Hue are controlled directly by Roomie so I’m not sure what the use case is anyway. That seems incredibly inefficient to send a Hue command through an ISY when it could be sent directly or even through the native iOS HomeKit API either of which are going to be much more efficient than going through a third system.

Hi Will, I will pass on the message to UD, re Hue yes I agree, for controls and changing colors etc, adding into RR via HomeKit is great, however eisy/isy automation @ programs is very good and there are a lot more other nodes, hue was just an example that I stated, as of now none of the node servers works in RR, so it’s just a general interface issue…again l will inform UD

Response from UD…

Supporting PG3 Node Servers and/or ZMatter Nodes will require them to make changes. I believe their integration is of our firmware version 4.x versions, 5.x added new device types. There is not much we can do if they do not upgrade their integration.

Most of the static commands (i.e. Insteon) will continue to work but new commands (i.e. node servers) may not work unless they have the same command definitions accepted by Insteon… ISY does not require polling if subscriptions are implemented, this is true in both 4.x and 5.x.

Right, that’s my point. This is the communication process that is based on “wait until a user complains and then hope you find the API changes”. So if I plugin an ancient ISY box that was called the ISY994, will it auto-update to that version with the problem? Or is this specific to a new box?

I never tired this with the old isy, that is now removed and cannot reinstall…the new box is the eisy unit

They’ll need to send us a box then for whatever this is. We’d also need use cases that make this make sense given that the use cases so far in this thread seem redundant with existing functionality as per above.

UD says if RR requests a developer box they can send one thanks….

Will, the big change was with their 5.x software. It’s more flexible and can run on a number of devices including COTS x64 boxes. It’s best now to think of “ISY” as software that can run on a variety of platforms as opposed to thinking of ISY as a physical device. In addition new 5.x ISY software supports a plug-in architecture whereby developers can expose a hierarchy of nodes to ISY which can then be controlled in a relatively generic way through the ISY APIs and UI. A node hierarchy is analogous to a file system. A non-leaf node is a unit of organization. A leaf node is a device or other thing that can be acted upon (on, off, up, down, etc.) HTH.