The need for a better user interface for ISY. Does it exist?

[kewashi]

On 3/25/2020 at 11:54 PM, madcodger said:

Thanks for the ideas and guidance here, and for making a great product. Perhaps @kewashi would also like to become involved in this, so thanks for the mention.

Hi everybody - I spent the week updating HousePanel and developing introductory YouTube videos that I plan to post tomorrow. I think when you see these you will see that HousePanel is the future of smart home GUI’s. The ISY interface is fully customizable and built on industry standard CSS and HTML5 tech. I would love to hear your feedback. 
 

Michel - I found and squashed the bug we discussed. I also added some new goodies that I think you will like. 

Whether you like HousePanel or not, my advice is for ISY to insist on a solution that is flexible and based on industry standards. If there is a better option than HousePanel then go for it  I haven’t seen one.

stay tuned. 
 

 

[madcodger]

@kewashi I am willing to take a look at HousePanel and have started to do so. However, when I read things on your site about using it with "even a smartphone" (i.e., as a last resort / not really designed for that) and that it operates on a user-hosted website, it makes me a bit wary, for a solution to what I had in mind when I started this thread. Feel free to correct any misperceptions I have.

My hesitation is that I don't have the time, and at this point maybe not the skills, to spend as much or more time setting up and managing an interface as I spent setting up my ISYs. That's not to say I don't think this has value for some folks, and I applaud you for building it. But what I had in mind when I started this thread was a better user interface that "just works" with the ISY.

Frankly, if someone could give me Agave or Mobilinc that actually works with my devices (all z-wave) , I'd be overjoyed because I can download them, spend maybe an hour or so getting them configured to my ISYs, and then I could just USE them. I can pull out my phone, check statuses or turn something on or off, and move on to the other 100 things I have to do that day. If the ISY operates reliably (as it always does), then in that scenario I'm not going to get a call from my wife that something on her "house app" won't work, or now "looks funny". I DON'T WANT to spend a lot of time configuring tiles and managing yet another thing. There might be a market for that, but what I'm hoping for, frankly, is a "ready made" solution, but one that is better than what we currently have, as those simply don't work with many popular devices and device types.

If House Panel (or for others reading this, candidates such as Home Assistant) can do that, awesome. I will happily hand you a couple of hundred bucks per year for that, for my wife and me. But if it's basically another hobby, I'm chock-full of those, and a lot of people I know are in the same position. We want a reliable, reasonably priced solution for home automation like the ISY. We're willing to spend time setting that up. Now we just want to access it for monitoring and control, without going through the same level of effort for the interface itself.

Edited March 28, 2020 by madcodger

[kck]

I'll point to the softconsole system that I run as another thing to look at.  Free and open source if anyone wants to try it, to tinker with it, or change it.  Also to some of the UDI or HA discussion, it supports both.  Actually, I'd suggest that anyone starting out to build a user interface think hard about exactly this (i didn't originally because I only had the UDI stuff).   Most of the function of a hub is fairly general - send on to node, send dim to node, . . .  If you create some general notion of a hub then the interface begins to become quite independent of it and you are free to use multiple hubs if that suits your needs with no user visibility.  I actually run UDI at one of our houses along with HA for some devices that originally were not easily supportable from UDI (e.g., Sonos) and HA at the other house.  Yet there are control screens that happily have buttons the happen to ping into either hub.  The thermostat screens look identical no matter which hub controls them (Insteon Tstat at original house and 2 Nests at second house).  Some of my consoles have screens that reach into both houses using 2 HA hubs and the UDI.  I offer this not so much to advertise softconsole (I make it available and support it but it is a hobby and hence of no monetary value to me) but to point out that good architectures should increasingly disconnect the HI side of things from the back end.  Actually, in that regard the work being done on the Lovelace interface for HA is quite good.  Were I starting now I might well have either just used that or at least based my console on it.  In any case, I have 8+ consoles on my network, my wife loves them, and they are co-managed over the network so any one of them can handle maintenance for any of the others.  The configuration for the console is crappy - legacy of the modest goals I had when starting out so you've been warned.

Edited March 28, 2020 by kck

[kewashi]

11 hours ago, madcodger said:

But if it's basically another hobby, I'm chock-full of those, and a lot of people I know are in the same position.

I completely agree and totally get it.  HousePanel at present is transitioning from "hobby" mode to "pro" mode - but it isn't there yet. I just finished making some videos that given instructions for setting it up. Next I will make an automatic script. Next I am investigating an automated setup that just works by installing onto a Polisy box. Its all work in progress. I know there is a market out there for this for all the reasons you stated which is why I'm motivated to make the transition. Stay tuned. 

In the meantime, if you or others want to use it as-is, these videos should help:

 

[kewashi]

12 hours ago, madcodger said:

However, when I read things on your site about using it with "even a smartphone" (i.e., as a last resort / not really designed for that) and that it operates on a user-hosted website, it makes me a bit wary, f

The documentation on www.housepanel.net is woefully out of date - and it was written for the SmartThings and Hubitat version that was riding on top of a web server. The ISY modified version is a pure Node app that works great on a smart phone or tablet. It is also a ton easier to set up as the videos explain. With that said, there is a lot to do to migrate out of hobby mode.

[madcodger]

14 hours ago, kewashi said:

I completely agree and totally get it.  HousePanel at present is transitioning from "hobby" mode to "pro" mode - but it isn't there yet. I just finished making some videos that given instructions for setting it up. Next I will make an automatic script. Next I am investigating an automated setup that just works by installing onto a Polisy box. Its all work in progress. I know there is a market out there for this for all the reasons you stated which is why I'm motivated to make the transition. Stay tuned. 

In the meantime, if you or others want to use it as-is, these videos should help:

 

Basically, I'm hoping we can build support for a really well designed system (or multiple systems) to "go pro". I'd really like to see something we can simply buy, install, and use - without lots of tinkering. I realize  you're not there today, and really applaud your efforts. The same would apply to helping existing user interfaces improve (enhanced focus on UI, better z-wave support, etc).
 

So, what can we in the community do to help, for you and for others, to improve the user interface(s) for the ISY and get them from where they are today, to a robust system one can simply buy, install, spend a few minutes configuring, and then just use?  What do you need from us?

 

[kewashi]

7 hours ago, madcodger said:

So, what can we in the community do to help, for you and for others, to improve the user interface(s) for the ISY and get them from where they are today, to a robust system one can simply buy, install, spend a few minutes configuring, and then just use?  What do you need from us

Hey @madcodger  I am fully in line with you and working on a proposal to do just that.  I have been in discussions with @Michel Kohanim about this and I owe him that proposal. I'm working on it as we speak.  One thing you and others can do to help is to provide feedback on alternative user interfaces.  I am mocking up a few screens that I would like to use this community to iterate with me to get them just right. Once the mocked up screens are good, I can then fill in the code behind them.  Another thing you and others can do to help is provide me with quotes like the ones in your prior post that I have permission to use in my proposal. This will serve as the "voice of the customer" if you will. Finally, if you know anyone who is a really good "node.js" developer looking for remote work, and who wouldn't be too expensive (I'm thinking of gifted young people looking for some exposure) please send them my way. I'm not interested in high priced SW consultants.

I will come back in this thread soon with the first mockup.  Until then let me just share that my initial thinking is to completely ditch the ISY Finder java launcher and the Java admin console. In it's place would be a Node-driven HTML5 interface, assisted with VUE or jQuery (or both), launched from any browser. This interface would display to a user all available nodes and perform all both end-user and admin functions served by the Java app. It would also replace the ISY Portal functionality found at: https://my.isy.io/index.htm with a modern look. FInally, I envision this running as a Node server on a Polisy box so it would be integrated in with the Polyglot service -- but I need to do some more studying to figure out how that would work. In short, it would pull together the following three disparate GUI's - and add an end-user dashboard functionality with the current HousePanel feature. And of course it would be mobile friendly.

 

[kewashi]

On 3/28/2020 at 3:21 PM, kck said:

Actually, I'd suggest that anyone starting out to build a user interface think hard about exactly this (i didn't originally because I only had the UDI stuff).   Most of the function of a hub is fairly general - send on to node, send dim to node, . . .  If you create some general notion of a hub then the interface begins to become quite independent of it and you are free to use multiple hubs if that suits your needs with no user visibility.  I actually run UDI at one of our houses along with HA for some devices that originally were not easily supportable from UDI (e.g., Sonos) and HA at the other house.  Yet there are control screens that happily have buttons the happen to ping into either hub. 

Hey @kck thanks for this post and this observation.  As I was writing HousePanel I came to this same realization. This is why 90% of the code is generic and it supports three types of smart home hubs - SmartThings, Hubitat, and ISY. The ISY port was drop-dead easy because of the points you are making.  With this system you can also mix and match items from multiple hubs onto a single tile, and so on and so forth. The key is the visual is abstracted from the server back end, so what the user sees is hub independent. There are some caveats because some hubs just act differently - for example, ISY hubs have no concept of thing type while SmartThings does. Anyway, your point is well taken and has been a guiding design principle behind HousePanel from its very early days.

[madcodger]

@kewashi First, feel free to use any of my earlier comments as "voice of the customer" as long as you keep them in the context and meaning in which they were originally written.

Next, I do fear we are a bit out of alignment on what I'm personally looking for. While I do want to see the current, java-based admin console retired, that's not my main concern. And, I think UDI is working on that, already ( @Michel Kohanim can confirm or comment if desired). The current admin console is a pain, but we can log into it to set things up, and that's not something that must be accessed frequently. The need I see is for a better mobile interface, that offers a quick, easy to understand and use view of devices already set up in the ISY. I'm not sure I see that developing here, but perhaps I'm wrong.

Also, having a solution that CAN run on Polisy is great. But requiring Polisy, as opposed to a RPi-based solution, is probably a non-starter at present for me, and perhaps many others. Because Polisy was not yet ready tp replace the ISY, I just bought a second ISY, and of Polisy is not ready as a replacement by summer or so, I'll be buying a third ISY. My only node server is to connect a weather station, which doesn't justify a Polisy (or three). That's not to say you shouldn't make something for Polisy, but personally I'm not going to buy one just for this. I remain hopeful that a solid UI can be developed that simply allows for improved access to the ISY 994 from a mobile device, not as a replacement to the admin console.

 

[HABit]

@kewashi  You seem to have developed a reusable UI interface based on the paradigm of a server-based presentation layer feeding a smart terminal/browser. It appears to have some interesting features to it and no doubt will be appealing to some in the UDI community. It even appears as if UDI may adopt it officially, from what you are saying. However, it isn’t suitable for my use as @madcodger previously pointed out: I need to have either an RPi or Polisy to use it. I see the worth of node servers as additional instrumentation (or data sources) for the ISY, in whatever form it eventually takes. However, having to contend with the Linux OS is a non-starter, it’s a hobbyist approach. As soon as you must sys-gen an O/S, or provision it with packages, run linkers, etc., that means if I was selling that as a solution, I’m forever tied to doing maintenance when the O/S crashes, or worse is hacked by some lunatic and whatever malevolence/mischief that results in. Then am I going to have an ancillary box hanging on the wall to run the NS for the UI?

I guess I don’t understand why the need for the additional layer at the server, rather than having the UI generation in an intelligent client. Having the UI present in a browser is not desirable either. I use the UDI Ajax browser page to do rudimentary maintenance, testing, and changing variables to enable/disable certain operations. It’s great for that, but if I handed it to my wife, she would hand it right back with the long-used expression: “I’ll look at it later...”, meaning - are you kidding? UI’s on mobile devices seem to work best by using the built-in presentation layer objects, which have been long thought through by the device manufacturer for acceptability by their clients. I’m sure this is a challenge that could be worked out eventually, but it will be a challenge to get it right on the multitude of devices, models, physical attributes available for use. 

Many talented folks here on the Forum have developed their own UI solutions, whether PC or even mobile based. I think that’s how Mobilinc got started. And if UDI suddenly said, no more WSDK/REST services, but must use through some NS, especially if it wasn’t open, to get all UI, I think the user base here would moan.

For me, it’s the old argument we had at my company many years ago: Server-based client UI’s vs Intelligent client/consumer UI’s. We ran a dual development to evaluate both approaches. Served CSS, etc in browser containers were interesting, but could not be adapted as easily to varying needs, nor by clients. Eventually the intelligent clients won because for our business model we needed to be able to change the UI for almost every client (business models typically change little, but corporate culture is extremely variable). The intelligent UI’s won because we continued to refine the concept into encapsulated data presentation objects in general containers. After that we even allowed end-users to completely modify their presentation layer using simple scripting (about as difficult as the ISY control script), eventually further reducing it to motile UI objects with point, drag and click configuration.

So turning whatever business modeling skills/intellect which has survived my youth to the ISY, I see it primarily as a controller that vends data, not as a server that also defines the way that that data should be consumed. So whether the product” of the ISY - data, is consumed by some automation which performs a function of the end-user’s definition, or is being displayed for visual consumption, I hope, will always be left to each customer.

I will probably continue looking at a mobile consumer/UI application, as a hobby, as I have my own needs which can’t seem to be met with an off the shelf app, so am inspired to work on this now. 

I don’t want to sound discouraging, as it seems you have rapidly adapted some other automation system’s UI app to work with ISY, and more options are always good. However, you did ask for feedback, so wanted to express my opinion of why this approach would not work for me, and perhaps others.

Good luck with your endeavors.

[larryllix]

24 minutes ago, SeeGreen said:

@kewashi  You seem to have developed a reusable UI interface based on the paradigm of a server-based presentation layer feeding a smart terminal/browser. It appears to have some interesting features to it and no doubt will be appealing to some in the UDI community. It even appears as if UDI may adopt it officially, from what you are saying. However, it isn’t suitable for my use as @madcodger previously pointed out: I need to have either an RPi or Polisy to use it. I see the worth of node servers as additional instrumentation (or data sources) for the ISY, in whatever form it eventually takes. However, having to contend with the Linux OS is a non-starter, it’s a hobbyist approach. As soon as you must sys-gen an O/S, or provision it with packages, run linkers, etc., that means if I was selling that as a solution, I’m forever tied to doing maintenance when the O/S crashes, or worse is hacked by some lunatic and whatever malevolence/mischief that results in. Then am I going to have an ancillary box hanging on the wall to run the NS for the UI?

I guess I don’t understand why the need for the additional layer at the server, rather than having the UI generation in an intelligent client. Having the UI present in a browser is not desirable either. I use the UDI Ajax browser page to do rudimentary maintenance, testing, and changing variables to enable/disable certain operations. It’s great for that, but if I handed it to my wife, she would hand it right back with the long-used expression: “I’ll look at it later...”, meaning - are you kidding? UI’s on mobile devices seem to work best by using the built-in presentation layer objects, which have been long thought through by the device manufacturer for acceptability by their clients. I’m sure this is a challenge that could be worked out eventually, but it will be a challenge to get it right on the multitude of devices, models, physical attributes available for use. 

Many talented folks here on the Forum have developed their own UI solutions, whether PC or even mobile based. I think that’s how Mobilinc got started. And if UDI suddenly said, no more WSDK/REST services, but must use through some NS, especially if it wasn’t open, to get all UI, I think the user base here would moan.

For me, it’s the old argument we had at my company many years ago: Server-based client UI’s vs Intelligent client/consumer UI’s. We ran a dual development to evaluate both approaches. Served CSS, etc in browser containers were interesting, but could not be adapted as easily to varying needs, nor by clients. Eventually the intelligent clients won because for our business model we needed to be able to change the UI for almost every client (business models typically change little, but corporate culture is extremely variable). The intelligent UI’s won because we continued to refine the concept into encapsulated data presentation objects in general containers. After that we even allowed end-users to completely modify their presentation layer using simple scripting (about as difficult as the ISY control script), eventually further reducing it to motile UI objects with point, drag and click configuration.

So turning whatever business modeling skills/intellect which has survived my youth to the ISY, I see it primarily as a controller that vends data, not as a server that also defines the way that that data should be consumed. So whether the product” of the ISY - data, is consumed by some automation which performs a function of the end-user’s definition, or is being displayed for visual consumption, I hope, will always be left to each customer.

I will probably continue looking at a mobile consumer/UI application, as a hobby, as I have my own needs which can’t seem to be met with an off the shelf app, so am inspired to work on this now. 

I don’t want to sound discouraging, as it seems you have rapidly adapted some other automation system’s UI app to work with ISY, and more options are always good. However, you did ask for feedback, so wanted to express my opinion of why this approach would not work for me, and perhaps others.

Good luck with your endeavors.

This may be short sighted. Think of this server software living on a polisy along with ISY, polyglot and your 18 NSs. Now you would  access it from another computer just as you do ISY and every other webpage now. The aim will be to access all of this from your favourite browser and no extra packages needed, such a java that the admin console requires now.

In the end, this is what UDI is aiming for, the way I understand it, and this is the objective of all, if not most, software designers. We all have these browsers loaded with support graphics and goodies so why would software writers want to duplicate all that?

Personally, I am not that fond of the photo background and room style screens as, although it looks great and works well with a only a few items placed on it, a full blown HA system will mask the background to the point of looking like a messy confusion of colours. I will still need a maintenance console based on lists and tree formats of my items and programs, so I won't need to search for that smart mousetrap I was sure I placed under the kickboard  of the cupboards.

Yeah, I am one of those that try to avoid remote control systems. I feel they are a failure of a HA system. But we are all not perfect and still need some remote control.

Edited March 30, 2020 by larryllix

[markv58]

I built my own mobile UI and have been using it exclusively now and it does exactly what I want it to do. Everyone is different as are their home automation setups so developing a catch all mobile app can't be done, if you want something like that you will have to get your hands dirty. I have Agave and eK ISY but neither do exactly what I want or look like I want them to look.

I shared my first setup on the forum and am working on a new UI with feedback and sliders that is easier for someone to setup as they like using the template that I will share when I finish.

With some simple instructions and a bit of effort anyone can modify the template to suit their needs. Here are some screen shots of the work in  progress.

Edited March 30, 2020 by markv58

[HABit]

@markv58 Exactly!

Looks good for your requirements and sounds like you are well on your way to making it even better.

Are you using a Droid (looks like from screen). Did you develop the app in the native smart phone language?

[markv58]

1 minute ago, SeeGreen said:

@markv58 Exactly!

Looks good for your requirements and sounds like you are well on your way to making it even better.

Are you using a Droid (looks like from screen). Did you develop the app in the native smart phone language?

That is iPhone but will do Android too although I don't have one right now to test on, but I'm sure I can dig up one for that. I'm using a guiDesigner then transferring to an app on the phone.

The learning curve has been a bit long for me but a template will cut that down for others and only requires info that is easy to get from ISY and paste into the system. I'm getting info from node servers too and have figure out how to send commands to change some settings. Some info comes from state variables that I setup and some directly from Z-wave and Insteon devices. Scenes and programs are used to do some things and direct control works some devices. It really isn't that hard once you wrap your noggin around it.

I'm accessing cameras from Blue Iris but some can be accessed directly although BI is better because the feeds are funneled through an already existing port through the firewall.

I have nothing else to do since the lockdown so this is how I'm occupying my time.

[HABit]

@markv58

Sounds really good. I like you ideas and have had similar thoughts about the possibilities, (although little progress so far). I have been slogging through wrapping WSDK/REST into callable container/objects, so can totally appreciate what you have probably had to work through. Someone else here on the Forum (I read a while ago) mentioned that they had already worked through using .Net for REST calls, and sent their code to help someone else just starting out. I was thinking of trying to find the post and ask to see how they did it. If a set of interface calls could be made and published for .Net, it would accelerate folks trying to do iPhone development and cross-platform development too. That was one of my original goals.

I love the NS/Poly concept for extending the ISY for control/monitoring, and thought the missing piece is on the "deliverables" (data/UI) side where the same could be accomplished. The actual UI would be left to the imagination and ingenuity or end-users, although I wonder how long it would take before a simple to use "container" app would emerge given the collective creative ability of people in the UI community.

Look forward to seeing your work if you share it.

[markv58]

It is possible for me to set up the app for someone and push it to their phone remotely. I would need some basic information from the API:Rest of the ISY to do that. That way someone could have a custom UI without the hassle. I would require a modest fee for the service of course but the overall cost would not be out of line with some other apps. Updates could be done remotely as well when a new device was added or replaced. I wonder what the interest would be in something like that.

[lilyoyo1]

I'm with @larryllixin that I don't really see the need for an app especially if the system is designed for automation from the ground up. Having used apps from RTI, control 4 and other high end systems, if I were to use something, I would want it to mimic those. It's great to try and add so much information to something but reality is, it'll probably cause more issues than it solves. Besides great design, the high end systems does things right by putting the necessary information at your fingertips vs trying to do what the main software does and be the designer for the system. 

Simplicity is the key for me. Take C4 for example. You have a few tabs that allow you to quickly open want you want whether it be AV, security, lights, etc. I'd want to have one tab that would allow me to see pertinent information only such as only the rooms with lights on vs a million devices to dig through to see what's on and off.

If used as an interface for a mounted tablet, I'd want to be able to control what's on the home screen per room. For example, the tablet for the living room would show living room stuff, Master bed would show stuff for that. While you could always access other rooms, I would want the ability for each room to have its own home screen for ease of use. 

 

[markv58]

I agree. I use an app rarely, usually to operate the garage OH door when I'm mowing the lawn or to run the Leave and Arrive programs that are part of the automation. Voice command is my preferred manual control outside of the automation. Most use is when I'm out of town to mimic occupation in a random fashion. A room by room control panel on a raspberry pi with a touch screen might be useful.

[larryllix]

54 minutes ago, lilyoyo1 said:

I'm with @larryllixin that I don't really see the need for an app especially if the system is designed for automation from the ground up. Having used apps from RTI, control 4 and other high end systems, if I were to use something, I would want it to mimic those. It's great to try and add so much information to something but reality is, it'll probably cause more issues than it solves. Besides great design, the high end systems does things right by putting the necessary information at your fingertips vs trying to do what the main software does and be the designer for the system. 

Simplicity is the key for me. Take C4 for example. You have a few tabs that allow you to quickly open want you want whether it be AV, security, lights, etc. I'd want to have one tab that would allow me to see pertinent information only such as only the rooms with lights on vs a million devices to dig through to see what's on and off.

If used as an interface for a mounted tablet, I'd want to be able to control what's on the home screen per room. For example, the tablet for the living room would show living room stuff, Master bed would show stuff for that. While you could always access other rooms, I would want the ability for each room to have its own home screen for ease of use. 

 

My belief is that this fails in the end mainly due to HA people having so many devices.

Now suppose you have 100 devices with say 2 nodes each. You have a fancy looking app to remote control these items. Sure you can select so many items to put on each small cell phone page to keep the clutter down. Now you have 75 pages and need a directory listing to select the page you want? Possibly a search engine to find the device or page you need for that remote control?

or

You have to select the prime devices that you will control. Where will the others be when you need to tweak that ventilator speed once in a blue moon? 

In the end the user will have to spend hours and hours setting up a complex system and that will turn off every potential "one click install"  user that only wants a fancy remote control system.

IOW: Fancy would be nice but the more home controlled devices we have the longer it will take to set up a "simple user GUI system" and the less people will support it.

OTOH: a few years ago, a nice touch pad on the wall with fancy graphics and user programmable boxes would have been really nice. Now, I would not want a touch pad on my wall and prefer to just voice my remote controls. 12 different colours as well as 4 different brightness levels for one set of bulbs takes a lot of buttons, physical or on a screen.

To make this a tech jump it is going to take a lot of touchpad ingenious. I personally don't like touchpads and avoid them whenever possible.  I will never get out a cell phone, and run an app to unlock my doors when I can just walk up to any door and unlock it with one finger and a 4-6 digit code. I haven't had a key in my pocket for 5-6  years now. None of my pants pockets have any sewing in them either. .

 

@Michel Kohanim
OTOH: This could make a great and fancy app to go with the "return for credit against our new polisy" ISY994s  that UDI could sell cheaply, complete  with a TW521? serial port X10 transmitter, for usage with the fancy app and an ISY Portal subscription for Alexa/GH vocal support.

This system could be used along with all the cheap and unwanted X10 devices out there. For maybe $100+ plus  ISY Portal subscription fees, you could have a one way remote home control system using the cheapest devices going and a fancy app. Recycle, reduce, reuse,?  
Not for HA users!

 

Edited March 30, 2020 by larryllix

[lilyoyo1]

40 minutes ago, markv58 said:

I agree. I use an app rarely, usually to operate the garage OH door when I'm mowing the lawn or to run the Leave and Arrive programs that are part of the automation. Voice command is my preferred manual control outside of the automation. Most use is when I'm out of town to mimic occupation in a random fashion. A room by room control panel on a raspberry pi with a touch screen might be useful.

I have a vacation program that runs when we're out of town. It mimics or scrubs when home and send notifications for things we may not worry about when home.

[larryllix]

3 minutes ago, lilyoyo1 said:

I have a vacation program that runs when we're out of town. It mimics or scrubs when home and send notifications for things we may not worry about when home.

With LED lighting now, we can run the lights in an almost clone pattern of being home. The $0.01 - $0.02 worth of energy is worth it.

[lilyoyo1]

17 minutes ago, larryllix said:

My belief is that this fails in the end mainly due to HA people having so many devices.

Now suppose you have 100 devices with say 2 nodes each. You have a fancy looking app to remote control these items. Sure you can select so many items to put on each small cell phone page to keep the clutter down. Now you have 75 pages and need a directory listing to select the page you want? Possibly a search engine to find the device or page you need for that remote control?

or

You have to select the prime devices that you will control. Where will the others be when you need to tweak that ventilator speed once in a blue moon? 

In the end the user will have to spend hours and hours setting up a complex system and that will turn off every potential "one click install"  user that only wants a fancy remote control system.

IOW: Fancy would be nice but the more home controlled devices we have the longer it will take to set up a "simple user GUI system" and the less people will support it.

OTOH: a few years ago, a nice touch pad on the wall with fancy graphics and user programmable boxes would have been really nice. Now, I would not want a touch pad on my wall and prefer to just voice my remote controls. 12 different colours as well as 4 different brightness levels for one set of bulbs takes a lot of buttons, physical or on a screen.

To make this a tech jump it is going to take a lot of touchpad ingenious. I personally don't like touchpads and avoid them whenever possible.  I will never get out a cell phone, and run an app to unlock my doors when I can just walk up to any door and unlock it with one finger and a 4-6 digit code. I haven't had a key in my pocket for 5-6  years now. None of my pants pockets have any sewing in them either. .

 

I agree with what you say which is why I don't personally have a need for one. What you say is also why (if I did) I would only want to see what's on vs the status of every device. 

Even though I have keypad locks, I still keep a key to be on the safe side. While I can always go to another door, why go through all that

[kewashi]

Well.... first, let me say WOW!!!   I clearly picked open a scab here which tells me that there is clearly a need for a unified clear vision for how ISY hubs will enable a world class end user experience.  I read through all the above posts and took away the following observations and made the following reactions:

• First - it is clear that what HousePanel does and what my vision for what it will become is unclear to most people. This isn't anybody's fault - I'm still a newbie here and I haven't taken the time to really show all of its dimensions. I will try to debunk some of the myths below, but more to come as I pull together my full plan
• Thanks for the feedback about the need to focus on end consumer experience instead of replacing the Java client. That is actually good news for me since that is where HousePanel is currently focused. If @Michel Kohanim already has plans to replace the Java client I can skip that part. I thought I understood the need for it so I will await clarification from him.
• The WAF acceptance factor is front and center on most people's minds. Sorry for the sexist acronym - this could be HAF too... you get my point. As it turns out the entire initial motivation for HousePanel was this factor - my wife hates the SmartThings app and she hated the sterile look of ActionTiles, so I made her a colorful dashboard. In the process I built it so that it can look sterile too. I also built it so it can fit the form factor of a mobile phone and look like a better mobile app (when you put a link on the home screen to most people it looks and works just like an app). What I failed to explain about HousePanel is that multiple user logins are supported and some can be mobile-first logins with different screen sizes and bigger icons, etc. I'll put a demo video together for that.
• One commend about why a Node server in the middle... well with that design it allows multiple end points to be served that look different per above. The assumption I think was that HousePanel is a server based client UI. That assumption is incorrect. The server in HousePanel knows next-to nothing about the client. The look and feel of the client is all based on how the browser renders the tiles using industry-standard CSS files that can be changed by the user or the installer. This is where the notion of "skns" comes in that I haven't explained yet. This will come soon.
• One comment about fears that it will require a Polisy can be dismissed. The HousePanel node app can and will run on both the Polisy box or a Raspberry Pi. It just runs faster on the Polisy box. The only open question is I can't yet figure out how I would support easy deployment on a rPI. For the Polisy I have a mental image of how I would merge HousePanel into a Polyglot node server for easy auto installs.  I need to noodle on that more.
• For those of you that wrote your own UI for ISY I think that is great. What I think is missing is the abstraction of these one-off solutions into a standard that can scale. If this community adopts the HousePanel standard, imagine a library of shared "skins" or a professionally developed library of skins anyone could purchase and install into their HousePanel installation. All of the demos shown above can be easily replicated with just a tiny amount of skin development in HousePanel. So imagine people who would otherwise develop a bespoke app, could now just develop a bespoke HousePanel skin. I know this ins't fair because I haven't described the "skinning" feature of HousePanel at all and there is no video about it yet -- it is on my "todo" list.
• Some of you noted that using apps or wall touch pads are "out of date" and today the preferred UI is voice. For those that just want voice, this is already available. I found the voice features of connecting ISY to Alexa quite easy and flexible. My own experience going back to the WAF factor is that most people don't remember what to say to turn on lights or perform other actions in a smart home. I chuckle all the time at my wife who yells at Alexa to do stuff that she doesn't know how to do. My vision for HousePanel is to have easy to use visuals to control your smart home. Those can be repurposed old Android phones with 4 buttons on them, or a 10" Fire tablet with multiple controls.
• Nobody asked about this but I wanted to talk about it anyway, and that is HousePanel includes a "rule engine" that allows installers to build logic rules that span across multiple hubs, so you can do things like "if your office door (which is tied to a SmartThings hub) closes, turn off the Insteon light tied to your ISY hub. 
• Finally, visual tiles in HousePanel can do much more than control ISY nodes. They can invoke web pages, send a POST command to a web service, or invoke a series of commands defined by an installer. Imagine setting this up to do a sequence of events frequently done in a home or on a smart phone.

Okay - I'll stop. The feedback above and comments above were just what I was hoping for. Thank so much everyone.  If you haven't done so already, please download and try out HousePanel. I posted a bugfix version 2.229 last night that is pretty stable. 

Cheers, Ken

 

[asbril]

9 minutes ago, kewashi said:

Well.... first, let me say WOW!!!   I clearly picked open a scab here which tells me that there is clearly a need for a unified clear vision for how ISY hubs will enable a world class end user experience.  I read through all the above posts and took away the following observations and made the following reactions:

• First - it is clear that what HousePanel does and what my vision for what it will become is unclear to most people. This isn't anybody's fault - I'm still a newbie here and I haven't taken the time to really show all of its dimensions. I will try to debunk some of the myths below, but more to come as I pull together my full plan
• Thanks for the feedback about the need to focus on end consumer experience instead of replacing the Java client. That is actually good news for me since that is where HousePanel is currently focused. If @Michel Kohanim already has plans to replace the Java client I can skip that part. I thought I understood the need for it so I will await clarification from him.
• The WAF acceptance factor is front and center on most people's minds. Sorry for the sexist acronym - this could be HAF too... you get my point. As it turns out the entire initial motivation for HousePanel was this factor - my wife hates the SmartThings app and she hated the sterile look of ActionTiles, so I made her a colorful dashboard. In the process I built it so that it can look sterile too. I also built it so it can fit the form factor of a mobile phone and look like a better mobile app (when you put a link on the home screen to most people it looks and works just like an app). What I failed to explain about HousePanel is that multiple user logins are supported and some can be mobile-first logins with different screen sizes and bigger icons, etc. I'll put a demo video together for that.
• One commend about why a Node server in the middle... well with that design it allows multiple end points to be served that look different per above. The assumption I think was that HousePanel is a server based client UI. That assumption is incorrect. The server in HousePanel knows next-to nothing about the client. The look and feel of the client is all based on how the browser renders the tiles using industry-standard CSS files that can be changed by the user or the installer. This is where the notion of "skns" comes in that I haven't explained yet. This will come soon.
• One comment about fears that it will require a Polisy can be dismissed. The HousePanel node app can and will run on both the Polisy box or a Raspberry Pi. It just runs faster on the Polisy box. The only open question is I can't yet figure out how I would support easy deployment on a rPI. For the Polisy I have a mental image of how I would merge HousePanel into a Polyglot node server for easy auto installs.  I need to noodle on that more.
• For those of you that wrote your own UI for ISY I think that is great. What I think is missing is the abstraction of these one-off solutions into a standard that can scale. If this community adopts the HousePanel standard, imagine a library of shared "skins" or a professionally developed library of skins anyone could purchase and install into their HousePanel installation. All of the demos shown above can be easily replicated with just a tiny amount of skin development in HousePanel. So imagine people who would otherwise develop a bespoke app, could now just develop a bespoke HousePanel skin. I know this ins't fair because I haven't described the "skinning" feature of HousePanel at all and there is no video about it yet -- it is on my "todo" list.
• Some of you noted that using apps or wall touch pads are "out of date" and today the preferred UI is voice. For those that just want voice, this is already available. I found the voice features of connecting ISY to Alexa quite easy and flexible. My own experience going back to the WAF factor is that most people don't remember what to say to turn on lights or perform other actions in a smart home. I chuckle all the time at my wife who yells at Alexa to do stuff that she doesn't know how to do. My vision for HousePanel is to have easy to use visuals to control your smart home. Those can be repurposed old Android phones with 4 buttons on them, or a 10" Fire tablet with multiple controls.
• Nobody asked about this but I wanted to talk about it anyway, and that is HousePanel includes a "rule engine" that allows installers to build logic rules that span across multiple hubs, so you can do things like "if your office door (which is tied to a SmartThings hub) closes, turn off the Insteon light tied to your ISY hub. 
• Finally, visual tiles in HousePanel can do much more than control ISY nodes. They can invoke web pages, send a POST command to a web service, or invoke a series of commands defined by an installer. Imagine setting this up to do a sequence of events frequently done in a home or on a smart phone.

Okay - I'll stop. The feedback above and comments above were just what I was hoping for. Thank so much everyone.  If you haven't done so already, please download and try out HousePanel. I posted a bugfix version 2.229 last night that is pretty stable. 

Cheers, Ken

 

Ken, thanks for your explanation. As a low level amateur techie, some of it was beyond my understanding. As I mentioned earlier, I will install HousePanel when it will be as easy as adding a nodeserver on Polisy. However the point that I want to make is  that, while I use voice commands with both Alexa and Google Home, I definitely want the screen based control. I have the Administrative Console open all day on my different computers, and also use Mobilinc Pro (I also have Mobilinc X, but find Pro more useful). However, the Administratice Console is not visually attractive and I have my hopes on HousePanel.

[kewashi]

As a step toward showing the "skin" feature of HousePanel, the image below is what my home setup looks like when I switched over the the "skin-modern" skin showing a more sterile clean look and feel.