Thread: Re: [Embedlets-dev] JINI SmartHome framework
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Gregg G. W. <gr...@sk...> - 2003-12-03 16:43:08
|
>Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >_______________________________________________ > >Gregg, > >What do you know about this JINI based smarthome framework?: > >http://www.sun.com/br/comms_1021/feature_homes.html This was shown in the Jini Fest at JavaOne this past spring. I did not look at it in depth at that time. They had a lot of foundation stuff in place, but were still tying it all together. It sounds like they've made some progress towards getting it all working together. They were talking about open source and sharing at Jini Fest. Technical stuff: They are using a number of powerful features of Jini. ServiceUI allows the user interface to be provided by the server via downloaded code. This is similar to the applet model, but a local Java application is the host of the interface, not your web bowser. ServiceUI includes the notion of toolkit specific UIs so that the client can ask for a UI that supports its toolkit (such as swing vs AWT, and with CDC/RMI a J2ME toolkit too). They have Javaspaces in use for holding the current state of things and for managing leased access to resources. They've got X-10 interfaces for simple controls. There is, as alluded to, some nice layering of responsibilities to allow differing devices and protocols to be plugged into the system. The use Jini services extensively, and I think they are using the Surrogate stuff for some of the services related to stupid devices. This means that devices and controls dynamically find and recognize each other to adapt to changes in the system quickly and easily. I can't draw a very exact picture of the system that I saw then, it's been a while. But, nevertheless, they have used Jini extensively, and their application shows a lot of the power associated with it. The number one issue though is still having to have a J2SE1.4 capable computer somewhere in the network to provide the surrogate host at a minimum, and the remainder of the Jini tools too. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Gregg G. W. <gr...@sk...> - 2003-12-03 23:33:37
|
>That pretty much precludes the usage of TINI/TStik... A Systronix JStamp or >JStik "might" cut it though... Not enough "Horse-Power"; just a thought, >IMHO. > >I didn't get enough TINI "Horse-Power" when trying to keep track of eight >(or more) X10 power modules... I abandoned that idea (after a year of trying >to optimize the code), and used a Dell laptop instead. 8D (I would have >preferred a Systronix TStik!). Hi Kelly! The important thing is that the surrogate model lets devices such as the TStick and JStamp and muviem devices do simply what they do best. They just need a comms path back into the house network so that they can 'see' the surrogate host using whatever protocol. So, the devices could use blue tooth, or a simple manchester coded fsk over 400mhz/900mhz. There are lots of possibilities. In this way, the work is distributed to be done by devices that can do a particular job the best. The low cost devices can be deployed in larger numbers to meet economy of scale, and the comms path can be whatever it takes to make it happen (flashing lights or otherwise :-) ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Kelly S. <be...@ea...> - 2003-12-04 14:25:03
|
Dear Greg - Re: "do simply what they do best". But determining what they may do best, may be a lesson in frustration (as I found out with the _MAXIMUM_ number of X10 modules that were "usable"), where a considerable amount of development time may have to be (actually was) trashed, just to find out "what that _CANNOT_ do best". There is no really good way to determine such limitations in advance, of actually trying it out in the development cycle. And only to find out that "You can't get there from here". So, you find out the hard way... My only saving grace, was that I developed the code (and found the limitations out of interest only), and was not under-the-gun to actually produce a viable product, that worked not just some of the time, but _ALL_ of the time! It would be great to have some sort of "metric" to really find out what platform can "do best"; but I don't have a crystal-ball, that would tell me (i.e., after its too late in the project). What I wound up with was a "potential" (but working) _EXAMPLE_ONLY__ for TINI\X10 code, that falls apart "in the real world". That is, when you hit the maximum number of "devices" (such as the X10 power modues), as the limitation. To say that it was a disappointment to find this out (after a year), is an understatement. Comment? Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Gregg G. Wonderly Sent: Wednesday, December 03, 2003 3:34 PM To: emb...@li... Subject: Re: [Embedlets-dev] JINI SmartHome framework Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ >That pretty much precludes the usage of TINI/TStik... A Systronix JStamp or >JStik "might" cut it though... Not enough "Horse-Power"; just a thought, >IMHO. > >I didn't get enough TINI "Horse-Power" when trying to keep track of eight >(or more) X10 power modules... I abandoned that idea (after a year of trying >to optimize the code), and used a Dell laptop instead. 8D (I would have >preferred a Systronix TStik!). Hi Kelly! The important thing is that the surrogate model lets devices such as the TStick and JStamp and muviem devices do simply what they do best. They just need a comms path back into the house network so that they can 'see' the surrogate host using whatever protocol. So, the devices could use blue tooth, or a simple manchester coded fsk over 400mhz/900mhz. There are lots of possibilities. In this way, the work is distributed to be done by devices that can do a particular job the best. The low cost devices can be deployed in larger numbers to meet economy of scale, and the comms path can be whatever it takes to make it happen (flashing lights or otherwise :-) ----- gr...@cy... (Cyte Technologies Inc) ------------------------------------------------------- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Gregg G. W. <gr...@sk...> - 2003-12-04 15:12:10
|
>But determining what they may do best, may be a lesson in frustration (as I >found out with the _MAXIMUM_ number of X10 modules that were "usable"), >where a considerable amount of development time may have to be (actually >was) trashed, just to find out "what that _CANNOT_ do best". One of the important things it sounds like you learned is that there are in fact classes of problems that particular platforms are not good for. A Java programming environment that supports realtime (soft or hard, or near) is much different from a Java programming environment that does not. The TINI appears to have a lot of overhead in its JVM implementation that creates unpredictable behavior for certain classes of problems. I've not had a chance to use the TINI that I have yet, but I keep trying to make a point to play with it. The muvium environment and the JStamp environment have a lot more potential for predictable behavior it seems. I've used the aJ100 processor via the PC-104 board and the dev board to develop some fairly serious applications. One was a remote alarm isolation multiplexor that included telnet/serial port management console, SNMP management and FTP file access. The other was an attitude indicator that read a serial stream from an attitude indicating device at 19200 and drew a nice color display (like you'd see in an airplane cockpit) of the ground reference, bank and pitch indication. It worked fine on the aJ100. I could easily use the threading model of Java to manage both the data input and the drawing so that the data rate was independent of the rendering. The use of the Java threading model, and monitors/semaphores make it possible to provide semi realtime rendering in a Java environment without realtime constraint support. But, you have to learn how to always provide a consistent data model based on data flow in, and data use by the rest of the application. If you have soft-realtime and non-realtime constraints that need nearly 100% of the CPU to be effective, then you have to learn how to segmentize those threads so that you provide your own quanta management within the system, allowing each thread to do the minimum that it needs to do to arrive at the next safe point. The RTSJ efforts remove this burden from the programmer. If more Java programming environment vendors provide implementations of RTSJ, then it will become trivial to write complicated timing-constraint based applications as long as the processor has enough power to satisfy the needs of the system. ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Kelly S. <be...@ea...> - 2003-12-04 15:48:25
|
Dear Gregg - I agree with all that you state here, and in a previous email by myself, I implied that a Systronix JStik/JStamp could _MAYBE_ "cut-the-mustard. But the real problem is that you have no metric for what a particular platform "can do best"...and I am not eager to spend endless hours to do "Thread Tuning" to find out! And, benchmarks are meaningless when the "rubber meets the road" (i.e., when you start to discover the limitations). IMHO - Somewhere between a TINI and a CRAY, is a solution, but finding that out can be a bitch! Its kind of like discovering that "Blackboard Pascal" can't do I/O in the real world without extensions (after spending a semester to find that out; saying to yourself, "Well, Pascal is useless!"). Maybe that's not a good analogy, but it was the first I could think of... 8D Thank you in advance, for allowing me the time to offend all of the Pascal Programmers out there. Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Gregg G. Wonderly Sent: Thursday, December 04, 2003 7:12 AM To: emb...@li... Subject: Re: [Embedlets-dev] JINI SmartHome framework Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ >But determining what they may do best, may be a lesson in frustration (as I >found out with the _MAXIMUM_ number of X10 modules that were "usable"), >where a considerable amount of development time may have to be (actually >was) trashed, just to find out "what that _CANNOT_ do best". One of the important things it sounds like you learned is that there are in fact classes of problems that particular platforms are not good for. A Java programming environment that supports realtime (soft or hard, or near) is much different from a Java programming environment that does not. The TINI appears to have a lot of overhead in its JVM implementation that creates unpredictable behavior for certain classes of problems. I've not had a chance to use the TINI that I have yet, but I keep trying to make a point to play with it. The muvium environment and the JStamp environment have a lot more potential for predictable behavior it seems. I've used the aJ100 processor via the PC-104 board and the dev board to develop some fairly serious applications. One was a remote alarm isolation multiplexor that included telnet/serial port management console, SNMP management and FTP file access. The other was an attitude indicator that read a serial stream from an attitude indicating device at 19200 and drew a nice color display (like you'd see in an airplane cockpit) of the ground reference, bank and pitch indication. It worked fine on the aJ100. I could easily use the threading model of Java to manage both the data input and the drawing so that the data rate was independent of the rendering. The use of the Java threading model, and monitors/semaphores make it possible to provide semi realtime rendering in a Java environment without realtime constraint support. But, you have to learn how to always provide a consistent data model based on data flow in, and data use by the rest of the application. If you have soft-realtime and non-realtime constraints that need nearly 100% of the CPU to be effective, then you have to learn how to segmentize those threads so that you provide your own quanta management within the system, allowing each thread to do the minimum that it needs to do to arrive at the next safe point. The RTSJ efforts remove this burden from the programmer. If more Java programming environment vendors provide implementations of RTSJ, then it will become trivial to write complicated timing-constraint based applications as long as the processor has enough power to satisfy the needs of the system. ----- gr...@cy... (Cyte Technologies Inc) ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
|
From: Kelly S. <be...@ea...> - 2003-12-03 17:09:53
|
All - Re: "The number one issue though is still having to have a J2SE1.4 capable computer somewhere in the network to provide the surrogate host at a minimum, and the remainder of the Jini tools too." That pretty much precludes the usage of TINI/TStik... A Systronix JStamp or JStik "might" cut it though... Not enough "Horse-Power"; just a thought, IMHO. I didn't get enough TINI "Horse-Power" when trying to keep track of eight (or more) X10 power modules... I abandoned that idea (after a year of trying to optimize the code), and used a Dell laptop instead. 8D (I would have preferred a Systronix TStik!). - Best regards, Kelly Smith -----Original Message----- From: emb...@li... [mailto:emb...@li...]On Behalf Of Gregg G. Wonderly Sent: Wednesday, December 03, 2003 8:43 AM To: emb...@li... Subject: Re: [Embedlets-dev] JINI SmartHome framework Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] _______________________________________________ >Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] >_______________________________________________ > >Gregg, > >What do you know about this JINI based smarthome framework?: > >http://www.sun.com/br/comms_1021/feature_homes.html This was shown in the Jini Fest at JavaOne this past spring. I did not look at it in depth at that time. They had a lot of foundation stuff in place, but were still tying it all together. It sounds like they've made some progress towards getting it all working together. They were talking about open source and sharing at Jini Fest. Technical stuff: They are using a number of powerful features of Jini. ServiceUI allows the user interface to be provided by the server via downloaded code. This is similar to the applet model, but a local Java application is the host of the interface, not your web bowser. ServiceUI includes the notion of toolkit specific UIs so that the client can ask for a UI that supports its toolkit (such as swing vs AWT, and with CDC/RMI a J2ME toolkit too). They have Javaspaces in use for holding the current state of things and for managing leased access to resources. They've got X-10 interfaces for simple controls. There is, as alluded to, some nice layering of responsibilities to allow differing devices and protocols to be plugged into the system. The use Jini services extensively, and I think they are using the Surrogate stuff for some of the services related to stupid devices. This means that devices and controls dynamically find and recognize each other to adapt to changes in the system quickly and easily. I can't draw a very exact picture of the system that I saw then, it's been a while. But, nevertheless, they have used Jini extensively, and their application shows a lot of the power associated with it. The number one issue though is still having to have a J2SE1.4 capable computer somewhere in the network to provide the surrogate host at a minimum, and the remainder of the Jini tools too. ----- gr...@cy... (Cyte Technologies Inc) ------------------------------------------------------- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 _______________________________________________ Embedlets-developer mailing list Emb...@li... https://lists.sourceforge.net/lists/listinfo/embedlets-developer |
Thanks for helping keep SourceForge clean.
X