From: Seann <nom...@ts...> - 2013-07-25 01:55:40
|
All, With all the recent activity on the list on updating Misterhouse, it got me thinking and working on a new UI for web access on my installation of Misterhouse. I see a lot of development for client side applications (Android and Iphone), but nothing on the web UI, outside of examples. Since I am going through this exercise on a complete overhaul on the UI to be more dynamic and flexible (Jquery, HTML5 elements, etc) for my own user case (and W.A.F.) I am interested in releasing it when it is finished, if there is interest. That being said, I would also like to see if anyone on the list has anything that they would like to see in the Web UI, so I can try to work that into my build. Regards, Seann |
From: <sta...@gm...> - 2013-07-25 01:59:00
|
I don't think I can endorse this strongly enough :) Among other things the existing web interface is not terribly responsive (OK, not at all) and very, very dated-looking. -- J On Jul 24, 2013, at 9:54 PM, Seann <nom...@ts...> wrote: > All, > > With all the recent activity on the list on updating Misterhouse, it got > me thinking and working on a new UI for web access on my installation of > Misterhouse. > I see a lot of development for client side applications (Android and > Iphone), but nothing on the web UI, outside of examples. > Since I am going through this exercise on a complete overhaul on the UI > to be more dynamic and flexible (Jquery, HTML5 elements, etc) for my own > user case (and W.A.F.) I am interested in releasing it when it is > finished, if there is interest. > That being said, I would also like to see if anyone on the list has > anything that they would like to see in the Web UI, so I can try to work > that into my build. > > > Regards, > Seann > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Kevin R. K. <ke...@kr...> - 2013-07-25 03:06:03
|
I started some work on a JQuery Mobile version that uses an AJAX-ish means of updating. I committed some of the work to a public repo here: https://github.com/krkeegan/mh-user-code I haven't updated it recently, but it may help. I also am wholly in favor of this. On Wed, Jul 24, 2013 at 6:58 PM, <sta...@gm...> wrote: > I don't think I can endorse this strongly enough :) Among other things the > existing web interface is not terribly responsive (OK, not at all) and > very, very dated-looking. > > -- > J > > On Jul 24, 2013, at 9:54 PM, Seann <nom...@ts...> wrote: > > > All, > > > > With all the recent activity on the list on updating Misterhouse, it got > > me thinking and working on a new UI for web access on my installation of > > Misterhouse. > > I see a lot of development for client side applications (Android and > > Iphone), but nothing on the web UI, outside of examples. > > Since I am going through this exercise on a complete overhaul on the UI > > to be more dynamic and flexible (Jquery, HTML5 elements, etc) for my own > > user case (and W.A.F.) I am interested in releasing it when it is > > finished, if there is interest. > > That being said, I would also like to see if anyone on the list has > > anything that they would like to see in the Web UI, so I can try to work > > that into my build. > > > > > > Regards, > > Seann > > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > ________________________________________________________ > > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Rick S. <mis...@co...> - 2013-07-25 03:03:13
|
It needs to be easy to update/meddle with. It's the main interface, so the most likely to want to be tinkered with At 09:54 PM 7/24/2013, Seann wrote: >All, > >With all the recent activity on the list on updating Misterhouse, it got >me thinking and working on a new UI for web access on my installation of >Misterhouse. >I see a lot of development for client side applications (Android and >Iphone), but nothing on the web UI, outside of examples. >Since I am going through this exercise on a complete overhaul on the UI >to be more dynamic and flexible (Jquery, HTML5 elements, etc) for my own >user case (and W.A.F.) I am interested in releasing it when it is >finished, if there is interest. >That being said, I would also like to see if anyone on the list has >anything that they would like to see in the Web UI, so I can try to work >that into my build. > > >Regards, >Seann > > >------------------------------------------------------------------------------ >See everything from the browser to the database with AppDynamics >Get end-to-end visibility with application monitoring from AppDynamics >Isolate bottlenecks and diagnose root cause in seconds. >Start your free trial of AppDynamics Pro today! >http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >________________________________________________________ >To unsubscribe from this list, go to: >http://sourceforge.net/mail/?group_id=1365 |
From: Lieven H. <li...@li...> - 2013-07-25 04:44:44
|
+1. To make the interface less confusing to new users or less technically inclined people it would be nice if it looked less complex. E.g. when you want to automate only a few devices the main page should only need to contain a few sub pages, one for controlling the devices and one for settings. Right now the main web page contains links to lots of pages that only work after some extended configuration (mail, security cams, agenda, phone calls, comics) and this can be confusing. Those links should only appear when the related code is configured in Misterhouse. A second thing that would be helpful for new users are specific setting pages for frequently used features. E.g. a setting page for configuring access to a mail account, or to a Google calendar account or an instant messaging server, or for configuration of a TTS engine. The way it is implemented Ruhr now would for experienced users but is IMHO a bit overwhelming for newcomers. I think that updating the web interface is key to making MisterHouse more appealing to new users. Lieven Op 25 jul. 2013 03:56 schreef "Seann" <nom...@ts...> het volgende: > All, > > With all the recent activity on the list on updating Misterhouse, it got > me thinking and working on a new UI for web access on my installation of > Misterhouse. > I see a lot of development for client side applications (Android and > Iphone), but nothing on the web UI, outside of examples. > Since I am going through this exercise on a complete overhaul on the UI > to be more dynamic and flexible (Jquery, HTML5 elements, etc) for my own > user case (and W.A.F.) I am interested in releasing it when it is > finished, if there is interest. > That being said, I would also like to see if anyone on the list has > anything that they would like to see in the Web UI, so I can try to work > that into my build. > > > Regards, > Seann > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Michael S. <mi...@st...> - 2013-07-28 13:41:37
|
On July 24, 2013 11:44 PM Lieven wrote: To make the interface less confusing to new users or less technically inclined people it would be nice if it looked less complex. E.g. when you want to automate only a few devices the main page should only need to contain a few sub pages, one for controlling the devices and one for settings. Right now the main web page contains links to lots of pages that only work after some extended configuration (mail, security cams, agenda, phone calls, comics) and this can be confusing. Those links should only appear when the related code is configured in Misterhouse. We have a good method of allowing users to include / exclude common code modules in the web interface now (it could use some AJAX though). A couple of options for making this better are: a. Place if/then checks in the web interface to only include pages / graphics if the related common code module is activated. This should be relatively straight forward to do by simply setting variables in the common code modules then checking for the variables in the web interface code. However, this may be more difficult to maintain in the long run that the next option. b. Redesign the web interface and common code such that the common code dynamically registers the web content. For instance the first page might list icons from a global hash. Once enabled Common Code might insert another icon in this hash. The interesting thing about this option is that user code could easily extend the interface without needing to wholesale replace existing web content (the way it works today). MH code upgrades should be much less painful for users that want to customize their web layout. Sincerely, Michael |
From: Lieven H. <li...@li...> - 2013-07-25 04:48:02
|
Hmm, autocorrect was not correcting this time... Op 25 jul. 2013 06:44 schreef "Lieven Hollevoet" <li...@li...> het volgende: > > The way it is implemented Ruhr now would for experienced users but is IMHO a bit overwhelming for newcomers. > The way it is implemented right now is OK for experienced users but is IMHO a bit overwhelming for newcomers. |
From: Seann <nom...@ts...> - 2013-07-25 05:44:08
|
On 7/24/2013 11:47 PM, Lieven Hollevoet wrote: > > Hmm, autocorrect was not correcting this time... > > Op 25 jul. 2013 06:44 schreef "Lieven Hollevoet" <li...@li... > <mailto:li...@li...>> het volgende: > > > > The way it is implemented Ruhr now would for experienced users but > is IMHO a bit overwhelming for newcomers. > > > > The way it is implemented right now is OK for experienced users but is > IMHO a bit overwhelming for newcomers. > Ok, So the general response is this is desired, which is good. I have some code, in Ajax/Jquery that mimics the current interface. What I have seen as desired is, in order of priority, and order of desired items: 1.) Updated interface that is more real time (When I update, say an insteon device, it shows the state change, without additional user interaction) 2.) Dynamic scaling based on user complexity (a small and/or novice installation should have a UI relevant to them, and be dynamically scalable) 3.) Be user friendly for non-computer science majors (or other technology guru's) The natural aspects for me (I maintain professional a niche technology so code documentation is not only second nature but sanity preserving) are documentation of what I do, and strict adherence to the coding standards of the project.) I will get to work on fleshing out what I have in mind with the requests from the MH list. My personal focuses are to create a dynamic and more real time interface that allows me to control the following aspects: 1.) Insteon real time control (I always feel silly and annoyed clicking multiple times to get the state I really know my gear is at) 2.) Omnistat real time control and monitoring (Should be simple based on the excellent work other users have produced for this) 3.) X10 control (can't be real time without additional sensors, so basic control built off of current setup) 4.) Real time reporting from home sensors (One Wire, Air Quality, etc) 5.) Eventual GUI based addition of additional code, sensors, etc (this can most likely be extended into a GUI basic install wizard, etc) I honestly think it would be neat to have a MH platform that you can browse to a site, configure your setup and get running. In a way that seems 'lazy' to me, but I do know more than enough people who, even though tech people, prefer a GUI to get moving quickly before customization. I also would want the CLI users to have the same end results at the GUI. The biggest thing I am looking for is a non-invasive installation, basically the GUI front end/client side (web browser) and the back end (JSON encoded, extended, but separate from the core build) in order to allow folk who don't need/want to upgrade everything, to have the new UI. I will also do my own best to ensure the style is both: Flexible so others to can themes and modern, without being cumbersome and tacky. Regards, Seann |
From: Lieven H. <li...@li...> - 2013-07-25 06:00:45
|
Hi Seann, Very cool. If you need help please report through the list. OT: I was wondering: are you already monitoring inside air quality and if you do: what sensor are you using? Also you state that you target real-time control of Insteon objects. What would it require to make it apply to other objects too? What is currently missing from the web interface for Insteon? Regards, Lieven Op 25 jul. 2013 07:44 schreef "Seann" <nom...@ts...> het volgende: > On 7/24/2013 11:47 PM, Lieven Hollevoet wrote: > >> >> Hmm, autocorrect was not correcting this time... >> >> Op 25 jul. 2013 06:44 schreef "Lieven Hollevoet" <li...@li... <mailto: >> li...@li...>> het volgende: >> > >> > The way it is implemented Ruhr now would for experienced users but is >> IMHO a bit overwhelming for newcomers. >> > >> >> The way it is implemented right now is OK for experienced users but is >> IMHO a bit overwhelming for newcomers. >> >> Ok, > > So the general response is this is desired, which is good. > > I have some code, in Ajax/Jquery that mimics the current interface. > > What I have seen as desired is, in order of priority, and order of desired > items: > > 1.) Updated interface that is more real time (When I update, say an > insteon device, it shows the state change, without additional user > interaction) > 2.) Dynamic scaling based on user complexity (a small and/or novice > installation should have a UI relevant to them, and be dynamically scalable) > 3.) Be user friendly for non-computer science majors (or other technology > guru's) > > The natural aspects for me (I maintain professional a niche technology so > code documentation is not only second nature but sanity preserving) are > documentation of what I do, and strict adherence > to the coding standards of the project.) > > I will get to work on fleshing out what I have in mind with the requests > from the MH list. > > My personal focuses are to create a dynamic and more real time interface > that allows me to control the following aspects: > 1.) Insteon real time control (I always feel silly and annoyed clicking > multiple times to get the state I really know my gear is at) > 2.) Omnistat real time control and monitoring (Should be simple based on > the excellent work other users have produced for this) > 3.) X10 control (can't be real time without additional sensors, so basic > control built off of current setup) > 4.) Real time reporting from home sensors (One Wire, Air Quality, etc) > 5.) Eventual GUI based addition of additional code, sensors, etc (this can > most likely be extended into a GUI basic install wizard, etc) > > I honestly think it would be neat to have a MH platform that you can > browse to a site, configure your setup and get running. In a way that seems > 'lazy' to me, but I do know more than enough people who, even though tech > people, prefer a GUI to get moving quickly before customization. > > I also would want the CLI users to have the same end results at the GUI. > > The biggest thing I am looking for is a non-invasive installation, > basically the GUI front end/client side (web browser) and the back end > (JSON encoded, extended, but separate from the core build) in order to > allow folk who don't need/want to upgrade everything, to have the new UI. > > I will also do my own best to ensure the style is both: Flexible so others > to can themes and modern, without being cumbersome and tacky. > > Regards, > Seann > > > > > > |
From: Seann <nom...@ts...> - 2013-07-25 06:23:18
|
On 7/25/2013 1:00 AM, Lieven Hollevoet wrote: > > Hi Seann, > > Very cool. If you need help please report through the list. > > OT: I was wondering: are you already monitoring inside air quality and > if you do: what sensor are you using? > > Also you state that you target real-time control of Insteon objects. > What would it require to make it apply to other objects too? What is > currently missing from the web interface for Insteon? > > Regards, > Lieven > > Op 25 jul. 2013 07:44 schreef "Seann" <nom...@ts... > <mailto:nom...@ts...>> het volgende: > > On 7/24/2013 11:47 PM, Lieven Hollevoet wrote: > > > Hmm, autocorrect was not correcting this time... > > Op 25 jul. 2013 06:44 schreef "Lieven Hollevoet" > <li...@li... <mailto:li...@li...> <mailto:li...@li... > <mailto:li...@li...>>> het volgende: > > > > The way it is implemented Ruhr now would for experienced > users but is IMHO a bit overwhelming for newcomers. > > > > The way it is implemented right now is OK for experienced > users but is IMHO a bit overwhelming for newcomers. > > Ok, > > So the general response is this is desired, which is good. > > I have some code, in Ajax/Jquery that mimics the current interface. > > What I have seen as desired is, in order of priority, and order of > desired items: > > 1.) Updated interface that is more real time (When I update, say > an insteon device, it shows the state change, without additional > user interaction) > 2.) Dynamic scaling based on user complexity (a small and/or > novice installation should have a UI relevant to them, and be > dynamically scalable) > 3.) Be user friendly for non-computer science majors (or other > technology guru's) > > The natural aspects for me (I maintain professional a niche > technology so code documentation is not only second nature but > sanity preserving) are documentation of what I do, and strict > adherence > to the coding standards of the project.) > > I will get to work on fleshing out what I have in mind with the > requests from the MH list. > > My personal focuses are to create a dynamic and more real time > interface that allows me to control the following aspects: > 1.) Insteon real time control (I always feel silly and annoyed > clicking multiple times to get the state I really know my gear is at) > 2.) Omnistat real time control and monitoring (Should be simple > based on the excellent work other users have produced for this) > 3.) X10 control (can't be real time without additional sensors, so > basic control built off of current setup) > 4.) Real time reporting from home sensors (One Wire, Air Quality, etc) > 5.) Eventual GUI based addition of additional code, sensors, etc > (this can most likely be extended into a GUI basic install wizard, > etc) > > I honestly think it would be neat to have a MH platform that you > can browse to a site, configure your setup and get running. In a > way that seems 'lazy' to me, but I do know more than enough people > who, even though tech people, prefer a GUI to get moving quickly > before customization. > > I also would want the CLI users to have the same end results at > the GUI. > > The biggest thing I am looking for is a non-invasive installation, > basically the GUI front end/client side (web browser) and the back > end (JSON encoded, extended, but separate from the core build) in > order to allow folk who don't need/want to upgrade everything, to > have the new UI. > > I will also do my own best to ensure the style is both: Flexible > so others to can themes and modern, without being cumbersome and > tacky. > > Regards, > Seann > > I apologize, I meant to hit reply all, not reply, I am planning on extending the JSON back end to allow me to leverage the control in the perl scripts, allowing me to get real time on most aspects of MH. The current focus is what I mentioned above, but with an easy extension to other elements. Right now I am focusing on my primary goals with real time, plus any of the most requested real time aspects that I can reproduce on my end. To answer Lieven's off topic question: Right now I am modeling my air monitoring and HVAC control off of the excellent work done by Marc Merlin (My house projects reflect what he has already done), plus building my own sensors boards based off of the concept of the Air Quality Egg (http://airqualityegg.wikispaces.com/AirQualityEgg). Sensor parts for the main board are: DHT22 Temp and Humidity sensor(This can and most likely be augmented by any temperature, humidity or combination sensor out there) MICS-5525 MICS-2710 MICS-2610 GP2Y1010AU0F All parts are google searchable, and I am planning on adding a PIC 18F4550 as the master controller to extend my MH setup (I also am looking at extending the HVAC zoning setup with the 4550, as well but that is a work in progress). If I can get my hands on something that can do pollen, I will hook that in as well, with three zones, Family room, main floor and master bedroom, to monitor for air quality. So far I have only found one Japanese device that does this, and is set for only Japanese pollen types. Regards Seann |
From: Monte F. <mo...@bv...> - 2013-07-25 17:26:21
|
I'm all for updates and improvements... :-) As a user (and not really a developer), my one request is that web interface enhancements/improvements/modifications try and maintain compatibility with the 3com Audrey appliances and the MrAudrey image that Pete Flaherty wrote to flash onto the Audrey devices. I rarely interface with my mh system for daily use other than through one of the Audrey touch screen devices that are scattered through my house; and I have become very accustomed to the push audio from my mh box to the audrey devices for announcements and the "grandfather clock". I don't think the audrey devices are capable of AJAX/JQuery/JavaScript in their built-in browser (I'm pretty sure that hardware pre-dates all that software technology). I know there has been work on making apps for various Android tablet devices to try and replace the audrey devices; but I can't afford to buy new tablets to have touch screen and remote speakers for the house at the moment... So, please; if possible....don't break the audrey functionality when doing updates/improvements to the mh web interface. :-) -Monte On Jul 25, 2013, at 2:22 AM, Seann wrote: > On 7/25/2013 1:00 AM, Lieven Hollevoet wrote: >> >> Hi Seann, >> >> Very cool. If you need help please report through the list. >> >> OT: I was wondering: are you already monitoring inside air quality and >> if you do: what sensor are you using? >> >> Also you state that you target real-time control of Insteon objects. >> What would it require to make it apply to other objects too? What is >> currently missing from the web interface for Insteon? >> >> Regards, >> Lieven >> >> Op 25 jul. 2013 07:44 schreef "Seann" <nom...@ts... >> <mailto:nom...@ts...>> het volgende: >> >> On 7/24/2013 11:47 PM, Lieven Hollevoet wrote: >> >> >> Hmm, autocorrect was not correcting this time... >> >> Op 25 jul. 2013 06:44 schreef "Lieven Hollevoet" >> <li...@li... <mailto:li...@li...> <mailto:li...@li... >> <mailto:li...@li...>>> het volgende: >>> >>> The way it is implemented Ruhr now would for experienced >> users but is IMHO a bit overwhelming for newcomers. >>> >> >> The way it is implemented right now is OK for experienced >> users but is IMHO a bit overwhelming for newcomers. >> >> Ok, >> >> So the general response is this is desired, which is good. >> >> I have some code, in Ajax/Jquery that mimics the current interface. >> >> What I have seen as desired is, in order of priority, and order of >> desired items: >> >> 1.) Updated interface that is more real time (When I update, say >> an insteon device, it shows the state change, without additional >> user interaction) >> 2.) Dynamic scaling based on user complexity (a small and/or >> novice installation should have a UI relevant to them, and be >> dynamically scalable) >> 3.) Be user friendly for non-computer science majors (or other >> technology guru's) >> >> The natural aspects for me (I maintain professional a niche >> technology so code documentation is not only second nature but >> sanity preserving) are documentation of what I do, and strict >> adherence >> to the coding standards of the project.) >> >> I will get to work on fleshing out what I have in mind with the >> requests from the MH list. >> >> My personal focuses are to create a dynamic and more real time >> interface that allows me to control the following aspects: >> 1.) Insteon real time control (I always feel silly and annoyed >> clicking multiple times to get the state I really know my gear is at) >> 2.) Omnistat real time control and monitoring (Should be simple >> based on the excellent work other users have produced for this) >> 3.) X10 control (can't be real time without additional sensors, so >> basic control built off of current setup) >> 4.) Real time reporting from home sensors (One Wire, Air Quality, etc) >> 5.) Eventual GUI based addition of additional code, sensors, etc >> (this can most likely be extended into a GUI basic install wizard, >> etc) >> >> I honestly think it would be neat to have a MH platform that you >> can browse to a site, configure your setup and get running. In a >> way that seems 'lazy' to me, but I do know more than enough people >> who, even though tech people, prefer a GUI to get moving quickly >> before customization. >> >> I also would want the CLI users to have the same end results at >> the GUI. >> >> The biggest thing I am looking for is a non-invasive installation, >> basically the GUI front end/client side (web browser) and the back >> end (JSON encoded, extended, but separate from the core build) in >> order to allow folk who don't need/want to upgrade everything, to >> have the new UI. >> >> I will also do my own best to ensure the style is both: Flexible >> so others to can themes and modern, without being cumbersome and >> tacky. >> >> Regards, >> Seann >> >> > > I apologize, I meant to hit reply all, not reply, > > I am planning on extending the JSON back end to allow me to leverage the > control in the perl scripts, allowing me to get real time on most > aspects of MH. The current focus is what I mentioned above, but with an > easy extension to other elements. Right now I am focusing on my primary > goals with real time, plus any of the most requested real time aspects > that I can reproduce on my end. > > To answer Lieven's off topic question: > > Right now I am modeling my air monitoring and HVAC control off of the > excellent work done by Marc Merlin (My house projects reflect what he > has already done), plus building my own sensors boards based off of the > concept of the Air Quality Egg > (http://airqualityegg.wikispaces.com/AirQualityEgg). > > Sensor parts for the main board are: > DHT22 Temp and Humidity sensor(This can and most likely be augmented by > any temperature, humidity or combination sensor out there) > MICS-5525 > MICS-2710 > MICS-2610 > GP2Y1010AU0F > > All parts are google searchable, and I am planning on adding a PIC > 18F4550 as the master controller to extend my MH setup (I also am > looking at extending the HVAC zoning setup with the 4550, as well but > that is a work in progress). > > If I can get my hands on something that can do pollen, I will hook that > in as well, with three zones, Family room, main floor and master > bedroom, to monitor for air quality. So far I have only found one > Japanese device that does this, and is set for only Japanese pollen types. > > Regards > Seann > > > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Brent D. <br...@de...> - 2013-07-25 17:28:21
|
I applaud your efforts and wish you luck in this much-needed endeavor. I attempted this several years ago before there were JS libraries like Jquery were available that supported Ajax functionality and in fact am still using the interface I developed on my MH install to this day. I use Ajax to dynamically update the display of things like 1-wire sensor values, weather station and alarm status information and timer values. At the time another rather abrasive member of this community ripped me a new one on the list for the methods I was using to attempt this and stated he was going to do something better. I had a discussion with Bruce, who was still actively involved in the project at the time, and we decided to let this person proceed with their attempt, and of course he never actually produced anything. Unfortunately that was pretty much the end of my interest in MH development… I'd encourage you to create your own public git branch so that others can actively see your progress, test and make contributions as it develops instead of waiting until you have something you feel is "complete" enough to fully share. Best, Brent On Jul 24, 2013, at 8:54 PM, Seann wrote: > All, > > With all the recent activity on the list on updating Misterhouse, it got > me thinking and working on a new UI for web access on my installation of > Misterhouse. > I see a lot of development for client side applications (Android and > Iphone), but nothing on the web UI, outside of examples. > Since I am going through this exercise on a complete overhaul on the UI > to be more dynamic and flexible (Jquery, HTML5 elements, etc) for my own > user case (and W.A.F.) I am interested in releasing it when it is > finished, if there is interest. > That being said, I would also like to see if anyone on the list has > anything that they would like to see in the Web UI, so I can try to work > that into my build. > > > Regards, > Seann |
From: Lieven H. <li...@li...> - 2013-07-25 18:50:19
|
Op 25-jul.-2013, om 19:11 heeft Brent DeShazer <br...@de...> het volgende geschreven: > [..] > I'd encourage you to create your own public git branch so that others can actively see your progress, test and make contributions as it develops instead of waiting until you have something you feel is "complete" enough to fully share. > I agree with this statement. Release often and early. The most efficient way to do this is to make your own branch so that other developers can test/help/lurk and otherwise motivate you! With this statement I don't mean you should write all code yourself of course, we can help out where needed once you start coding. Kind regards, Lieven. |
From: Brent D. <br...@de...> - 2013-07-25 17:46:49
|
I don't *think* anyone is talking about removing any of the existing web interfaces, just *adding* a new one using more modern technologies that can be utilized by those devices that support them like iOS and Android tablets/phones and of course PCs. On Jul 25, 2013, at 12:12 PM, Monte Freeman wrote: > > I'm all for updates and improvements... :-) > > As a user (and not really a developer), my one request is that web interface enhancements/improvements/modifications try and maintain compatibility with the 3com Audrey appliances and the MrAudrey image that Pete Flaherty wrote to flash onto the Audrey devices. > > I rarely interface with my mh system for daily use other than through one of the Audrey touch screen devices that are scattered through my house; and I have become very accustomed to the push audio from my mh box to the audrey devices for announcements and the "grandfather clock". > > I don't think the audrey devices are capable of AJAX/JQuery/JavaScript in their built-in browser (I'm pretty sure that hardware pre-dates all that software technology). > > I know there has been work on making apps for various Android tablet devices to try and replace the audrey devices; but I can't afford to buy new tablets to have touch screen and remote speakers for the house at the moment... So, please; if possible....don't break the audrey functionality when doing updates/improvements to the mh web interface. :-) > > -Monte |
From: Lieven H. <li...@li...> - 2013-07-25 18:51:55
|
Op 25-jul.-2013, om 19:46 heeft Brent DeShazer <br...@de...> het volgende geschreven: > I don't *think* anyone is talking about removing any of the existing web interfaces, just *adding* a new one using more modern technologies that can be utilized by those devices that support them like iOS and Android tablets/phones and of course PCs. > I second this. Monte, no need to get worried, nobody plans to remove the ia5 interface or to otherwise break existing functionality. Lieven. > On Jul 25, 2013, at 12:12 PM, Monte Freeman wrote: > >> >> I'm all for updates and improvements... :-) >> >> As a user (and not really a developer), my one request is that web interface enhancements/improvements/modifications try and maintain compatibility with the 3com Audrey appliances and the MrAudrey image that Pete Flaherty wrote to flash onto the Audrey devices. >> >> I rarely interface with my mh system for daily use other than through one of the Audrey touch screen devices that are scattered through my house; and I have become very accustomed to the push audio from my mh box to the audrey devices for announcements and the "grandfather clock". >> >> I don't think the audrey devices are capable of AJAX/JQuery/JavaScript in their built-in browser (I'm pretty sure that hardware pre-dates all that software technology). >> >> I know there has been work on making apps for various Android tablet devices to try and replace the audrey devices; but I can't afford to buy new tablets to have touch screen and remote speakers for the house at the moment... So, please; if possible....don't break the audrey functionality when doing updates/improvements to the mh web interface. :-) >> >> -Monte > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Monte F. <mo...@bv...> - 2013-07-25 19:17:16
|
On Jul 25, 2013, at 2:51 PM, Lieven Hollevoet wrote: > > Op 25-jul.-2013, om 19:46 heeft Brent DeShazer <br...@de...> het volgende geschreven: > >> I don't *think* anyone is talking about removing any of the existing web interfaces, just *adding* a new one using more modern technologies that can be utilized by those devices that support them like iOS and Android tablets/phones and of course PCs. >> > > I second this. Monte, no need to get worried, nobody plans to remove the ia5 interface or to otherwise break existing functionality. I suppose I should have phrased my message a little differently. I wouldn't have thought that anyone would be suggesting removing the ia5 interface.. At least I would hope not. :-) My request came more from the perspective of not designing a new web config/control interface for mh; that *required* something like AJAX/JavaScript, etc. even for access to basic/core configuration functions. I understand that we can't maintain backwards compatibility all the way to stone tablets and abacuses. :-) And that eventually these devices which have served so well for so many years will, alas; have to go the way of the dodo bird. I just wanted to interject a request to anyone who wants to start writing a new interface; and who may not even know why the ia5 interface and graphics set were created in the first place, to just please keep that in mind when designing/testing. :-) For reference, in case there's someone on the list who hasn't seen the MrAudrey code; Pete's web page for it is: http://www.mraudrey.net/MrAudrey.php No idea if he's still on the mh list or not, so just making sure his work gets referenced for history.. -Monte > > Lieven. > >> On Jul 25, 2013, at 12:12 PM, Monte Freeman wrote: >> >>> >>> I'm all for updates and improvements... :-) >>> >>> As a user (and not really a developer), my one request is that web interface enhancements/improvements/modifications try and maintain compatibility with the 3com Audrey appliances and the MrAudrey image that Pete Flaherty wrote to flash onto the Audrey devices. >>> >>> I rarely interface with my mh system for daily use other than through one of the Audrey touch screen devices that are scattered through my house; and I have become very accustomed to the push audio from my mh box to the audrey devices for announcements and the "grandfather clock". >>> >>> I don't think the audrey devices are capable of AJAX/JQuery/JavaScript in their built-in browser (I'm pretty sure that hardware pre-dates all that software technology). >>> >>> I know there has been work on making apps for various Android tablet devices to try and replace the audrey devices; but I can't afford to buy new tablets to have touch screen and remote speakers for the house at the moment... So, please; if possible....don't break the audrey functionality when doing updates/improvements to the mh web interface. :-) >>> >>> -Monte >> >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> ________________________________________________________ >> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 >> > > |
From: Seann <nom...@ts...> - 2013-07-28 02:40:05
|
On 7/25/2013 2:17 PM, Monte Freeman wrote: > > On Jul 25, 2013, at 2:51 PM, Lieven Hollevoet wrote: > >> >> Op 25-jul.-2013, om 19:46 heeft Brent DeShazer <br...@de... >> <mailto:br...@de...>> het volgende geschreven: >> >>> I don't *think* anyone is talking about removing any of the existing >>> web interfaces, just *adding* a new one using more modern >>> technologies that can be utilized by those devices that support them >>> like iOS and Android tablets/phones and of course PCs. >>> >> >> I second this. Monte, no need to get worried, nobody plans to remove >> the ia5 interface or to otherwise break existing functionality. > > I suppose I should have phrased my message a little differently. I > wouldn't have thought that anyone would be suggesting removing the ia5 > interface.. At least I would hope not. :-) > > My request came more from the perspective of not designing a new web > config/control interface for mh; that *required* something like > AJAX/JavaScript, etc. even for access to basic/core configuration > functions. > > I understand that we can't maintain backwards compatibility all the > way to stone tablets and abacuses. :-) And that eventually these > devices which have served so well for so many years will, alas; have > to go the way of the dodo bird. I just wanted to interject a request > to anyone who wants to start writing a new interface; and who may not > even know why the ia5 interface and graphics set were created in the > first place, to just please keep that in mind when designing/testing. :-) > > For reference, in case there's someone on the list who hasn't seen > the MrAudrey code; Pete's web page for it is: > > http://www.mraudrey.net/MrAudrey.php > > No idea if he's still on the mh list or not, so just making sure his > work gets referenced for history.. > > -Monte > > I am not looking at changing much under the hood, so I don't think this would impact existing use cases. Basically I am setting up an ia8 web directory and running all the web code out of there, tying back to the web bin directory, and most likely going to (attempt) create a new perl module for json, that expands what has been done in the past. This should also allow for testing with other devices, and be cross browser compatible. As I don't know anything about the Audry gear, outside of that it sounded neat when I started playing with Mr. House about 6 years ago, I can't say it will work at all with this (I don't know what works and what doesn't in the ia5 interface for these devices) but feedback on that would be nice, as I can work towards getting my code to support that gear in one way or another (If it doesn't work with my interface, i can use the client strings to push the device to the code that does work). I will start reading and decoding the MrAudry information that Monte posted and see if I can make this work on the Audry devices. Since it looks like it has to be flashed to work with anything new, I don't think it would be compatible, but my code shouldn't interfere with that. When I get the main portion of the code setup (basic menu's, basic status, etc) I will branch it out on GIT. From there I will be building out modules to plug into the main interface for each type of technology I have, with the hopes that it will be branched out for everything folk use. While I am looking at a single flat file that you have to alter manually in order to include modules, I would also like a setup wizard that writes this file, after selecting the available modules in the code base, but that is pretty far down the road at this point. Regards, Seann |