Topic: OneRemote (Read 25820 times)

JimH · « **on:** August 01, 2015, 06:46:53 pm »

This is the evolution of the home automation project I began thinking about in June. I may move this out to the main board in a few weeks. Your thoughts would be very welcome.

Thanks,

Jim

JimH · « **Reply #1 on:** August 01, 2015, 06:49:13 pm »

Edited August 25, 2015

OneRemote

The Internet of Things promises to bring many exciting changes, but controlling all of these new devices needs to be simple and easy to understand. If you buy a light bulb, you need to be able to screw it in and turn it on without downloading a new app for your phone and updating the firmware on the light bulb.

OneRemote is a complete solution for this problem. It is end-to-end, manufacturer to consumer. It is one simple app that can set up and control anything.

Technology

OneRemote is a cross-platform device management system. It is available for end users, installers, and manufacturers. It manages IoT devices in an organized way.

The user sees an easy way to set up and control devices. Smart apps and applications display easy-to-understand menus, built from Device Profile and Scene objects. These objects can be automatically acquired from a local or Internet source.

The system manages setup, control, and firmware updates for devices in the home or office. No other app is required.

Components

BOT -- Broker of Things (Local DB)

This is the local home or office hub and it provides the intelligence for each location. It is responsible for communications and control of the IoT devices.

BOT software from JRiver enables this intelligence. It can run on Windows, Mac, or Linux computers. The software includes a database of obects: device descriptions, room scenes, situations, and more.

These objects come from an Internet database (a DOT) where anyone can upload or download objects, or from manual entry by a user, installer, or manufacturer. It is for devices what Wikipedia is for information.

The BOT's can run on inexpensive, low-power devices like a Raspberry Pi, or on a high performance server.

The BOT's support communication over ZigBee, Z-Wave and other popular networks for controlling devices.

DOT -- Distributor of Things (Internet DB)

A DOT is at the center of this system. It is an Internet database of objects. BOT's can exchange objects with this DOT by a process similar to backing up and retrieving files.

Both upload and download are open to anyone, and a sophisticated "voting" mechanism rates them as users make choices.

For multiple descriptions of the same device, a user may choose which to download, and each download counts as a vote. Device descriptions that get more votes rise to the top and those which get few votes fall to the bottom and eventually off the list.

OneRemote App (for Users)

Apps or Applications on phones, tablets, or computers communicate with a BOT to set up and control devices. The app offers a simple, hierarchical menu, presenting choices for control. These menus are built from the objects that are acquired from a BOT, and they represent all the devices available in that location.

----------

As a picture:

Local <-------------------------------> Internet

App <-----------> BOT <-----------> DOT

Computer or Phone <--> Local Server <--> Internet Server

JimH · « **Reply #2 on:** August 01, 2015, 06:55:02 pm »

A couple of obvious questions are how this fits with JRiver Media Center and how would we pull it off? I'll try to address this.

I think that MC is a fine example of what home automation can be. Imagine sitting on your couch with a magic wand and drawing up whatever you want to watch or listen to. That's been our mission. That is a kind of home automation.

To make it happen, we must be very careful to continue our current work and preserve the great community we enjoy. That means we need to add people. And that means we need to increase our cash flow, which is already very good.

I want to be sure that it doesn't stress the current team and that they have the chance to be part of the new venture if they want to be. This should be fun for all of us.

JimH · « **Reply #3 on:** August 01, 2015, 07:02:08 pm »

The initial product we will sell will be a sidekick to MC. It will be a piece of software that runs on the OS's we now support. There will also be an Internet server that we (and possibly others) will run. There will be client programs that run on Android, iOS, Windows, OSX, and Linux.

We may offer a hardware device, similar to the Id, but under $200. But we may not have to do this. There are already many "hubs" that provide the link between the LAN and the devices.

JimH · « **Reply #4 on:** August 01, 2015, 07:10:28 pm »

I think we may offer the new product, OneRemote, as a pre-order to our existing users, probably for a nice discount.

It fits our skill set well. We have strong skills in networking, database, and device support already.

I also think it's a natural extension of what we do. I can imagine a Theater View that has a Home choice and it leads on to lighting, locks, cameras, intercom, and so on.

Both programs could stand alone and both could tie to the other. I think the joining could be very clean and logical.

JimH · « **Reply #5 on:** August 01, 2015, 07:12:50 pm »

I've spent some time testing and reading this week. I think the competition is SmartThings. They have a very nice hub that supports Z-Wave and ZigBee. It works well. Their app is very good. Samsung bought the company a year ago for $200 million. SmartThings raised $1.2 million on KickStarter a year or so before that.

JimH · « **Reply #6 on:** August 01, 2015, 07:23:12 pm »

We will do our best to support two or three of the most popular devices in each category at launch or soon after.

fitbrit · « **Reply #7 on:** August 01, 2015, 08:00:05 pm »

I'm very excited about this. I'm already thinking about making a living installing these systems for people with money, not time, in a few years!

jmone · « **Reply #8 on:** August 01, 2015, 11:21:40 pm »

Yeah this concept of a hub that abstracts each device & the protocols is a terrific idea and is more or less what MC does now for various media formats and devices. I look forward to this for my Intercom!

astromo · « **Reply #9 on:** August 02, 2015, 05:42:29 am »

I reckon this one is a bit of a holy grail.

I'm keen to see this one brought to reality..

gvanbrunt · « **Reply #10 on:** August 03, 2015, 04:41:46 pm »

I've actually got a lot of insteon devices and a universal devices hub. So if you want testing in that area let me know. I've been using it to automate my house for about 1.5 years. I also have it hooked up to MC via eventghost so I can play a movie and have the lights automatically dim...

My first suggestion is that for this to work, it has to be WAF friendly. There are lots, and lots of devices, hubs, and software in this space. Most are geek only. Or if they are not, just plain junk that you really don't want in your house. If you can take the disjointedness out of the space and make it user friendly you would have the market cornered. Item #2 is security. Many devices are a complete joke and offer hackers a direct route right into your home. This has to be rock solid security wise. The home automation space is a prime target of hackers and as more devices hit the market, the more they will target them. You don't want to be one of the companies that have already failed in this area.

Keep those two as a mantra and you can clean up in that space.

JimH · « **Reply #11 on:** August 03, 2015, 05:14:01 pm »

What is the "Universal devices hub"? Is it from Insteon? After Z-Wave and ZigBee, Insteon seems like the next most important.

raym · « **Reply #12 on:** August 03, 2015, 05:30:27 pm »

Harmony Home Hub has had a good crack at this:

http://www.amazon.com/Logitech-915-000238-Smartphone-Entertainment-Automation/dp/B00N3RFC4Q

gvanbrunt · « **Reply #13 on:** August 03, 2015, 07:58:33 pm »

Quote from: JimH on August 03, 2015, 05:14:01 pm

What is the "Universal devices hub"? Is it from Insteon? After Z-Wave and ZigBee, Insteon seems like the next most important.

I could be wrong but I believe Insteon and Z-Wave are bigger than ZigBee. From what I know about it ZigBee mostly started out as "green" oriented and the first devices were behind smart meter installations etc. It has gained interest as many third parties have jumped on the bandwagon after many power utilities embraced it for "smart meter" applications. I haven't really followed development much for a couple of years so I don't really know how far it has come.

A Universal Devices hub is like HomeSeer etc in that it allowed a few different manufacturers devices to be controlled. Insteon, ZWave and Zigbee. https://www.universal-devices.com/residential/isy994izw-series/ I use mostly Insteon with it and so far is "set and forget". As far as I remember the isy was the first "hub" to support Zigbee. It isn't for the non geek...

Hilton · « **Reply #14 on:** August 11, 2015, 08:13:09 am »

Some food for thought. IFTTT (now known as IF) type task support would be cool.

IF on its own now can do some pretty neat tricks.

Remember that story I told about walking up the path and the lights automatically turning on when you get home.

This is exactly what IF can do today. Amongst a heap of other cool things.

The device doesn't matter, it's the "App Broker", in this case IFTTT that makes the magic happen.

jmone · « **Reply #15 on:** August 11, 2015, 04:00:44 pm »

I can't find the article on line... but the tech writer in the local rag (Daily Telegraph in Sydney) was talking about how all of this is great stuff..... but it just does not work reliably. He was using IFTTT to read humidity readings to turn on/off a dehumidify at upper/lower limits and when it worked it was great. but many times it did not.

JimH · « **Reply #16 on:** August 24, 2015, 06:44:43 am »

Working on an ad / brochure / web page.

Description

Rough graphic design:

Arindelle · « **Reply #17 on:** August 25, 2015, 04:45:38 am »

broken for me too .. I suppose you have given some thought to the name

Just for info, Bang and Olufson have this packaged under OneRemote (plus the danish website here => http://shop.oneremote.dk/catalog/

JimH · « **Reply #18 on:** August 25, 2015, 05:24:25 am »

We own the .com domain:

http://www.oneremote.com

RoderickGI · « **Reply #19 on:** August 25, 2015, 09:05:17 pm »

Quote from: JimH on August 25, 2015, 05:24:25 am

We own the .com domain:

http://www.oneremote.com

http://www.onlyoneremote.com/
https://www.indiegogo.com/projects/oneremote-one-remote-for-everything-really#/story
http://www.presonus.com/products/Studio-One-Remote
http://www.aioremote.net/ and https://www.facebook.com/All.In.One.Remote

Product branding is a complex issue these days, with globalisation of most products.

JimH · « **Reply #20 on:** August 26, 2015, 02:53:30 am »

Work in progress. Click for a larger image.

gvanbrunt · « **Reply #21 on:** August 26, 2015, 12:18:34 pm »

How about just JRiver One. Or perhaps some funky spelling of the word. Oun with an oumlette or whatever it is called

raldo · « **Reply #22 on:** August 26, 2015, 05:13:57 pm »

I'm surprised that the issue of testability and fault finding hasn't come up yet. A user should know immediately what's wrong and where the problem is located.

This should be the number one priority of product development and perhaps a major product feature.

JimH · « **Reply #23 on:** August 27, 2015, 12:58:36 am »

Quote from: raldo on August 26, 2015, 05:13:57 pm

I'm surprised that the issue of testability and fault finding hasn't come up yet. A user should know immediately what's wrong and where the problem is located.

This should be the number one priority of product development and perhaps a major product feature.

I have no idea what you mean by that.

leezer3 · « **Reply #24 on:** August 27, 2015, 06:12:17 am »

Way too much text on that I think.
It needs self-explanatory pictures, and an absolute minimum of text; I'd say a couple of sentences at absolute most.

You're entering what to the average consumer is a crowded market (Think of the universal remotes you can pickup at the dollar store), and so you *must* be able to differentiate yourselves at a glance.
Text is all well and good, but something of that length will get glossed over very rapidly.

Fault finding-
I think what he means is that I press 'play' on my shiny new remote.
Nothing happens

Why?

Did the signal not get through?
Was the file not found?
etc. etc.

Same difference with lightbulbs- Why didn't my lights come on?
Do I need to change the bulb or what?

-Leezer-

JimH · « **Reply #25 on:** August 27, 2015, 08:35:44 am »

Quote from: leezer3 on August 27, 2015, 06:12:17 am

Way too much text on that I think.

This has been debated for a long time. I once read that you should use whatever space it takes in order to tell the complete story, and I believe this is true.

Here's a couple of discussions on the subject:
http://www.melissadata.com/enews/marketingadvisor/articles/0910c/1.htm

http://www.quicksprout.com/the-definitive-guide-to-copywriting-chapter-8/

If you just said "OneRemote from JRiver. It works.", I think you'd find a lot of skeptics.

This is a system, not just an app.

Out of curiosity, did you read the copy? Did you understand it?

leezer3 · « **Reply #26 on:** August 27, 2015, 12:51:06 pm »

I read it and understand the concept you're after

Some more cogent thoughts:
Too many acronyms- I'd shorten Broker of Things (BoT) to 'The Broker', similarly I'd chuck DoT for simply 'the/ our database', and loose the App from the end of OneRemote.
In essence, your document feels like something written by a programmer, not a marketing person.

Whilst that isn't necessarily a bad thing, at this stage, I'm not sure you should be looking at us for target feedback- We're essentially a bunch of technical people, who understand the references you're making.
You need to convince the masses that you can provide an interface that talks to everything they've got- They won't necessarily know or care which protocol their shiny new lightbulb uses, just that it can be controlled from 'an app'

To cite your first link:

Quote

As a marketer, if you've got a product that in general is like every other product of its kind, though maybe with a few value-added differences—there's no need to re-write the entire history of your product's invention in your sales copy.

The concept of a remote is not new

The concept of a universal remote is not new (As I mentioned earlier, the dollar store, or at least our European equivalent) has had them for ages)

The concept of an app as a remote is not new

What you're essentially doing IMHO is combining several existing technologies, that everyone has at least heard of into one continuous whole. What will make or break this is whether *it works*- Any sort of fiddling further than entering a model number, and I'm afraid you've probably lost.
A remote control has to be simple and intuitive.

An couple of examples of the way I'd be spinning this:
The Broker
You want some sort of graphic in here, the logo for the broker
'The Broker' is your local home or office hub.
It runs on anything from a Raspberry Pi to a high-power server, and transmits commands seamlessly to all your existing devices.
Adding another is simple- All it needs to do is ask our database for details.

One Remote
Snazzy screenshot, with a device superimposed to one side
Teamed with 'The Broker', our IOS/ Android app lets you control any device you choose, all on the tap of a button.

-Leezer-

JimH · « **Reply #27 on:** August 27, 2015, 01:17:16 pm »

Quote from: leezer3 on August 27, 2015, 12:51:06 pm

One Remote
Snazzy screenshot, with a device superimposed to one side
Teamed with 'The Broker', our IOS/ Android app lets you control any device you choose, all on the tap of a button.

Still better might be an app that does something.

I do appreciate your thoughts. At this point, the market is probably geeks so geek-speak might not be a problem.

I believe that the unique aspect of this is that devices can be represented by objects and we can create a market (paid or not) with them. These device objects can flow about the Internet and make setup easy or automatic.

In my opinion, jmone nailed it with this description above.

Quote from: jmone on August 01, 2015, 11:21:40 pm

... Yeah this concept of a hub that abstracts each device & the protocols ...

raldo · « **Reply #28 on:** August 27, 2015, 02:20:34 pm »

Quote from: JimH on August 27, 2015, 12:58:36 am

I have no idea what you mean by that.

I'm just saying that any kind of error in the system should be reported/detected by the system itself.

Say a device is low on battery then the user should know the location and state of the device. Or, say a device malfunctions. Other devices (or a watchdog) should notify the user on the state and location of the lost device. And so on.

JimH · « **Reply #29 on:** August 27, 2015, 02:43:03 pm »

Ok. I understand and agree. Thanks.

leezer3 · « **Reply #30 on:** August 27, 2015, 07:03:56 pm »

Quote from: JimH on August 27, 2015, 01:17:16 pm

Still better might be an app that does something.

I do appreciate your thoughts. At this point, the market is probably geeks so geek-speak might not be a problem.

I believe that the unique aspect of this is that devices can be represented by objects and we can create a market (paid or not) with them. These device objects can flow about the Internet and make setup easy or automatic.

In my opinion, jmone nailed it with this description above.

You see, that's another place I think you're going a little wrong.
There are millions of ordinary customers, *not* geeks who haven't yet realised they need this yet

(Wifi heating controls are taking off in a big way, and this will filter down into other bits of home automation before too long)
Think about what Apple and the original iPod did for MP3 players- It made them mainstream. That's where I'd be aiming for, with a product my grandmother could use, and geeks would be a secondary priority.

It's far easier to alienate people like my grandmother with an overly complex interface and masses of terminology than it is to market this to geeks

-Leezer-

fitbrit · « **Reply #31 on:** August 27, 2015, 09:46:26 pm »

Quote from: leezer3 on August 27, 2015, 07:03:56 pm

It's far easier to alienate people like my grandmother with an overly complex interface and masses of terminology than it is to market this to geeks

-Leezer-

I think the idea is to start with the geeks. But if that happens, I don't think there will be any turning back to make it appealing to non-geeks. Especially if the same geeks that make the geek version work on the non-geek evolution.

I am not that keen on DOT and BOT as the headings. I think the concept should be introduced in bold like The Broker and The Database, but you can then mention that they are called BOT and DOT.

As a sidenote, if there is an Id as a broker for the Internet of Things, can we please call it the IdIoT?

JimH · « **Reply #32 on:** August 27, 2015, 10:46:31 pm »

OK. Why don't you re-write it and I'll read. Seriously.

fitbrit · « **Reply #33 on:** August 27, 2015, 11:00:38 pm »

I'd like to give it a go, Jim, but I'm organising a big event at work that is on Saturday and Sunday, and am working every second that I am not parenting or on here

I could give it a go next week, but I don't want to promise anything.

JimH · « **Reply #34 on:** August 27, 2015, 11:03:31 pm »

I think the initial market is truly the technophile / geek. Grandmothers are a few years off.

A very important target are the manufacturers.

jmone · « **Reply #35 on:** August 28, 2015, 07:48:41 pm »

I'm pretty excited by this and think you are on the right track. I have a middleware background and this abstraction concept is now very mature in the app space. Regardless of the terminology and branding the key parts are:

- Adapters : These are the only specialised bits that and are required for each different device/system to be controlled. It can also be the hardest part as there are so many of them. Support from MFR can be key here especially if their API is not publicly documented, or worse a "hostile" mfr that hates these attempts as it pushes their brand awareness to the backgound in such systems.

- Mapping GUI : This is the GUI where users can create their rules. The purpose of this is to have a single GUI where you create Human Readable "maps" for what you want the system to do. It is normally functions by showing icons of the Adapters you have installed with pins for each of the available services exposed. You can then drag associations from one Adpaters Pin to another and apply transformation rules. An example would be, say you have adapters for your an "Environment Monitor" exposing a Pin for Temp, Humidity, Barametric Pressure etc, and also a simple "Power Supply Socket" with an On/Off pin. In the Mapping GUI you drag a connection from the "Environment Monitor Humidity Pin" to the "PS On/Off pin" and then apply some rules like if "Humidity > 90% turn ON" and "Humidity < 80% turn OFF". You can build the rules up into a workflow on conditional actions.

- Mapping Engine : This is the rules engine that runs and controls the maps (start, stop, pause etc) and provide reporting and error logging. One option is a "compiled" versions that includes all the adapters, maps, and engine in one runtime so you can deploy as an executable.

jmone · « **Reply #36 on:** August 28, 2015, 07:57:28 pm »

Quote from: leezer3 on August 27, 2015, 06:12:17 am

Way too much text on that I think.
It needs self-explanatory pictures, and an absolute minimum of text; I'd say a couple of sentences at absolute most.

jmone · « **Reply #37 on:** August 28, 2015, 09:17:30 pm »

Some more ramblings about Adapters that may be of use. First you have a few different "Types" pending what you want to do:
- API: Highest Level, most feature rich, real time and where most of the focus tends to be these days (eg MCWS) but don't forget,
- DB: Sometimes you don't have access to an API but you can read/write to a DB (eg modifying a field in MC)
- File: Lowest Level but still extremely useful (eg importing/exporting an MPL)

You also may want to consider a couple of commercial things on the Adapters:
- Which ones are you going to provide for as part of the core licence? (I'd start with MC of course, a couple of the big API based ones and also File, E-Mail, even IR),
- Which ones are you going to charge extra for (?)
- Are you going to have a Dev Kit so 3rd parties can develop, distribute and potentially sell adapters (I'd suggest Yes)

The good thing about this approach is once there is a bit of momentum in the marketplace you should see a rise in 3rd party adapters. From experience adapter development can be expensive and complex in some cases but letting 3rd parties have access to a tool kit outsources this nicely.

JimH · « **Reply #38 on:** August 30, 2015, 11:31:31 am »

Are you sure you don't want my job? I know you'd do a lot better at it.

I read your post before this one a couple days ago quickly, but didn't have time to study it.

Your thinking is close to mine. You just seem to have a formal education.

To reply to a couple of your comments...

Creating the device objects will be open to anyone. Manufacturer, installer, retailer, end user --- anyone. Build and upload it. Let people try it out and decide if it's good. This is the way the YADB database works now. It has a very clever (Gateley invented) voting system so the cream rises to the top.

Your triage of API, DB, File, is similar to what I've been thinking about. It's clear that many devices will fit neatly into an orderly system, but some won't. I think we just start with the low hanging fruit and work our way up. Some will be beyond our reach.

Starter set. Nest. Lutron. Schlage. And a couple more.

Manufacturers. Some will want their brand everywhere. Some will choose the path of least resistance. No app development or support needed.

Momentum. Yes. Good idea.

jmone · « **Reply #39 on:** August 30, 2015, 05:53:47 pm »

Nah, much more fun being being a "backseat driver" + I've heard about the size of those Minnesotan Mossies

The concept seems pretty well defined to me though like always the devil is in the details.

Another part on the system is if you will use a Queue to hold the messages for non real time processing and persistence.
- The example here is when a particular end point is not available. In my example of the "Environment Monitor" turns on/off the Dehumidifyer it all works well up till the Smart Power Socket is not available. Without a queue it would just fail. With a queue you can then set how persistent you want that activity to be before it fails. Eg keep trying for 1hr, 24hrs, forever.
- Another example may be with File input - output. You spit out a file but need to wait (some unspecified time) for a return file to be sent back before the next stage can happen. And it may never come back for some reason.
- Queues let you know where each Activity is up to, what is stuck, needs stopping, starting etc.

Also worth considering at this point is if these Activities are "atomic transactions" in that if they fail to complete do you roll back the prior actions or do they just stall. An example here would be an Activity may turn on a Receiver then instruct MC to play a song. If MC is down does the activity roll back so the Receiver is put back into Standby as it was originally?

The good thing with this whole OneRemote stack is you don't have to try to do it all at once, I'd suggest the core bit are a good Mapping Engine and some popular adapters with the Dev Kit. As the kinks are worked out on that you can then look at tackling persistence, atomic transactions etc once it gains a foothold.

I was always surprised what can be done with these stacks. Lots of fun!

JimH · « **Reply #40 on:** September 01, 2015, 05:07:25 am »

Here's a problem that I could use advice on.

Say that a manufacturer has a device like an Id or a DAC and they want to use OneRemote for setup and control.

There will need to be two way communication between the BOT or the APP and the device. Sometimes this will be easy to represent in a file, but sometimes it won't be easy.

My plan is this:

The device is represented by a file. In it are one or more images that represent the graphics for the page to be displayed in OneRemote. This will become the background of the setup page, for example. I think we just allow the object file to point to a URL that contains the image. This part seems not too difficult.

The harder part is how to describe the information that is displayed on the screen and the inputs needed.

For example, an Id might have settings for the audio output. Normally we could do this by labelling the input:

Audio Output [dropdown box]

and listing the choices.

Or a device might allow its name to be changed. We would need to do this:

Device Name [Enter any name]

and so on.

All of the data received by the app must be sent to the device. This means that the device needs to support an equivalent of MCWS.

The messy part is how does the device manufacturer tell us how to send it what it needs. I guess that a REST interface could tell us that. We could provide some source to the manufacturer if needed.

The bottom line is that it requires sophisticate communication and the client side needs to support several types of input as any programming language must.

OK, that's my plan. Where is it weak?

Thanks.

jmone · « **Reply #41 on:** September 01, 2015, 05:30:44 pm »

I'm on the road at present but a quick response:

Adapters: These are the specif bits of code that work on doing the transformation of each end user device interface (API, File, whatever) into a common abstraction for the Mapping engine exposing desired features. Each of these adapters are written for a particular target and can be used in a "disconnected" state to then create / dev maps and when connected actually pass the calls back and forward. The creation of the Adapters requires the developer to obviously understand both OneRemotes side (dev tool kit) and also the target system. The sole purpose of the Adapters are to abstract the target devices calls into that used by the OneRemote's Mapping tool. Users of the Mapping tool no longer need to know if the target device uses WS, custom API, Files, FTP or whatever. The adapter handles to translocation to whaterver the target device needs. Now you could also have a generic "REST/WS" adapter which probes for and exposes what is available.

Mapping Tool: This is the bit where the user then gets to "see" what calls are available and through the GUI / drop down etc then make connections and rules between these end points.

I'm not sure that makes any sense but if you want a Telcon hook up let me know.

Thanks
Nathan

JimH · « **Reply #42 on:** September 02, 2015, 01:15:30 am »

We sometimes use the word "shim" to describe what you call an adaptor. It translates calls from one piece of software to ones that another understands. It's just a small piece in the middle.

Thanks for the help and the offer of roadside assistance.

JimH · « **Reply #43 on:** September 04, 2015, 04:28:45 am »

We're working on a menu program that will allow a user to set up several levels of custom choices. The picture attached shows a first level with a list of:

Lighting
Temperature

The user can add more choices and is able to add background photos for the buttons from a gallery or by taking a picture.

At each level, the user will be able to add devices.

Or an xml file can specify how to build the whole menu, including pictures.

This may turn out to be flexible enough to be used in the PrettyFace project.

AndrewFG · « **Reply #44 on:** September 04, 2015, 10:22:22 am »

I haven't really been following this thread but I wonder if this is relevant..

http://myharmony.com/discover/harmony-api/

JimH · « **Reply #45 on:** September 06, 2015, 05:00:40 pm »

Sometime in the next week or two, the menu program should be working enough to get some feedback on how it works. It won't control anything, but you would be able to to set up a menu structure, and probably export it as an xml file that someone else could import.

I may put it on the Google Play Store and make it by invitation only, as we did with the early builds of JRemote for Android.

If anyone is interested in looking at it, and willing to provide feedback, please let me know.

Thanks.

JimH · « **Reply #46 on:** September 06, 2015, 05:03:51 pm »

Quote from: AndrewFG on September 04, 2015, 10:22:22 am

I haven't really been following this thread but I wonder if this is relevant..

http://myharmony.com/discover/harmony-api/

It's the right neighborhood. Thanks.

jmone · « **Reply #47 on:** September 06, 2015, 05:14:59 pm »

I'm keen to play

fitbrit · « **Reply #48 on:** September 06, 2015, 05:23:37 pm »

Quote from: JimH on September 06, 2015, 05:00:40 pm

Sometime in the next week or two, the menu program should be working enough to get some feedback on how it works. It won't control anything, but you would be able to to set up a menu structure, and probably export it as an xml file that someone else could import.

I may put it on the Google Play Store and make it by invitation only, as we did with the early builds of JRemote for Android.

If anyone is interested in looking at it, and willing to provide feedback, please let me know.

Thanks.

Is there a minimum version of Android in mind to run this?

JimH · « **Reply #49 on:** September 06, 2015, 05:27:53 pm »

I think it's something like 2.6, but that's from memory and may not be reliable. It should work with most Android devices.

INTERACT FORUM

Author Topic: OneRemote (Read 25820 times)