46
Developers / Re: 810 alpha2 no KDE desktop on MD.
« on: April 09, 2009, 03:22:48 pm »
This is a known problem right now and one of the few major problems remaining in Alpha
News:
Rule #1 - Be Patient - Rule #2 - Don't ask when, if you don't contribute - Rule #3 - You have coding skills - LinuxMCE's small brother is available: http://www.agocontrol.com
LinuxMCE sponsor
open.home.automation
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
47
Users / Re: "Should RS232 Be Dropped In Favor Of Other Protocols"?
« on: April 05, 2009, 05:08:12 pm »
I think you missed something above..
DCE (Data, Commands and Events) that was suggested above is the communications protocol of LMCE (developed and owned by Pluto). It abstracts the underlying protocol of the device you are trying to control. For example, if you send an ON command to a device, you don't need to worry about the protocol used to control the device, it will just happen automagically (if the device template is defined correctly and a driver has been written). Check out DCE in the wiki - its the backbone of LinuxMCE and understanding it is essential to anything you do in LMCE.
DCE (Data, Commands and Events) that was suggested above is the communications protocol of LMCE (developed and owned by Pluto). It abstracts the underlying protocol of the device you are trying to control. For example, if you send an ON command to a device, you don't need to worry about the protocol used to control the device, it will just happen automagically (if the device template is defined correctly and a driver has been written). Check out DCE in the wiki - its the backbone of LinuxMCE and understanding it is essential to anything you do in LMCE.
48
Developers / Re: Several enhancments for LinuxMCE security and smart home functionality
« on: April 03, 2009, 05:39:15 pm »
Yes, all of you changes sound like they would be excellent improvements to LinuxMCE! Any number of us on IRC freenode linuxmce-devel would be willing to help you get your changes in. You may also visit svn.linuxmce.org and submit a patch in a trac ticket. Thank you very much for your efforts and willingness to share!
49
Developers / Re: VIdeo from IP Cameras
« on: March 31, 2009, 09:30:35 am »
on the same note, it would be a waste terrible waste (in terms of processor and memory usage) to transcode from MJPEG or any other format on the fly to something that the broadcast video designobj can use (think about the overhead for someone who has 8 cameras... transcode them all on the fly?? On top of everything else the core has to do... I think not) . Not to mention that people with the in depth knowledge needed for video transcoding are not that easy to find. Another dowside is that latency would have to be introduced as a side effect of the transcoding. This is where a new designobj type to handle MJPEG streams makes (a lot of) sense... The stream is already there and there is almost no overhead to decode it.
50
Developers / Re: VIdeo from IP Cameras
« on: March 31, 2009, 07:59:31 am »
I have also been looking into this (among other Motion Wrapper and IP camera improvements). I think sticking with MJPEG would be the way to go initially, as it is very easy to decode in software and its supported by many cameras. I think we can make another command, Get_Video_Stream (a compliment to Get_Video_Frame). The implementation of Get_Video_Stream on a device level will intercept the MJPEG stream from the camera, strip its boundary markers (as there really isn't a tight standard and it is implemented differently from manufacturer to manufacturer), and resend them out with a standardized boundary marker. Then, as Thom suggested, in Orbiter we can either extend the Broadcast Video deisgnobj, or even make a separate MJPEG designobj. Then to make it work across the various platforms (pseudo code)-- if(implements_get_video_stream && is_onscreen_orbiter) { use_get_video_stream } else { use_get_video_frame } (this would mean that any device that implements get_video_stream would also have to implement get_video_frame to provide this compatibility)
I already have a working MJPEG decoder in Ruby for one of my IP cams as my camera didn't have a "snapshot" to static jpg functionality, so I parse the MJPEG stream in real time to construct a jpg image which is returned via Get_Video_Frame. Works quite well too
On a side note, if we provide such an implementation, motion wrapper could be used directly to serve the MJPEG stream
I already have a working MJPEG decoder in Ruby for one of my IP cams as my camera didn't have a "snapshot" to static jpg functionality, so I parse the MJPEG stream in real time to construct a jpg image which is returned via Get_Video_Frame. Works quite well too
On a side note, if we provide such an implementation, motion wrapper could be used directly to serve the MJPEG stream
51
Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!
« on: March 27, 2009, 12:08:05 am »
sorry - Yes, Andrew is correct. Still, it may be worth checking if it offers the types of features you are looking for
52
Installation issues / Re: LinuxMCE as DHCP server, NOT gateway!
« on: March 26, 2009, 08:48:38 pm »
Not an answer to your question, but you sound like a good candidate for Vera (www.micasaverde.com)
It is made by the creators of Pluto - and in simple terms its a Core running on DD-WRT... and its LMCE compatible (uses DCERouter). With your experience with DD-WRT, this might be right up your alley. Also, I think they're still doing an earlybird special where you can get a great price.
It is made by the creators of Pluto - and in simple terms its a Core running on DD-WRT... and its LMCE compatible (uses DCERouter). With your experience with DD-WRT, this might be right up your alley. Also, I think they're still doing an earlybird special where you can get a great price.
53
Users / Re: Advanced Scenario Question??
« on: March 26, 2009, 08:41:53 pm »
Seth - Look into the DCERouter delay command to get your delay. I believe the parameter is in minutes...
54
Feature requests & roadmap / Re: "Null User" - or a way to log out in general
« on: March 25, 2009, 03:00:13 am »
good suggestion guys... the "Guest" user could be added behind the scenes... Now just to figure out what a guest user would be allowed to do.....
55
Users / Re: "Tough Love In This Forum"
« on: March 25, 2009, 02:58:36 am »
Excellent addition to the community, congrats guys!
56
Developers / Re: Getting IP address from Device in GSD
« on: March 23, 2009, 03:44:13 am »
Pete
Could you post the information you have regarding controlling the box via telnet? I'd be interested in doing a c++ device for this, and integrating your instant queue with the normal datagrids
Could you post the information you have regarding controlling the box via telnet? I'd be interested in doing a c++ device for this, and integrating your instant queue with the normal datagrids
57
Installation issues / Re: DYNDNS Setting
« on: March 22, 2009, 08:49:35 am »
unfortunately your true WAN IP is most likely assigned to a modem or router before your LMCE box, and therefore the dyndns scripts aren't going to do you any good. On top of this, LMCE does not yet support a direct PPPOE connection (natively that is), so until that happens, there is no way for LMCE to know your WAN IP address.
I do however have a plan to make it work in these situations in the 0810 release.
I do however have a plan to make it work in these situations in the 0810 release.
58
Installation issues / Re: Box is hanging up from rtc: lost some interrupts at 1024Hz
« on: March 22, 2009, 02:09:51 am »
We need more information.. What chipset does your NIC use? Is it onboard? What motherboard?
NVidia NICs are notorious for causing these types of RTC errors on gigabit networks. I solved my similar problem by moving my slower external network to the NIC in question.
NVidia NICs are notorious for causing these types of RTC errors on gigabit networks. I solved my similar problem by moving my slower external network to the NIC in question.
59
Developers / Re: LMCE Launch Manager - name change suggestions please
« on: March 21, 2009, 10:40:22 am »
Also keep in mind that the original name is a bit leading (Launch Manager).. Sure, it can launch certain things on button presses (reloading the router, starting/stoping the core, etc) - but the biggest role it plays is doing cleanup when starting or reloading... Things such as running update scrips like UpdateAvailableSerialPorts.sh, StartCoreServices.sh, starting/restarting all children devices, etc. It basically does all the little cleanup work that keeps things running smooth from reload to reload.
Another role the old Launch Manager played was to keep the user informed of what was going on while waiting for a bootup, reload or regen process. Thats what the separate clients are for now...
Another role the old Launch Manager played was to keep the user informed of what was going on while waiting for a bootup, reload or regen process. Thats what the separate clients are for now...
60
Developers / LMCE Launch Manager - name change suggestions please
« on: March 21, 2009, 07:06:26 am »
As I am starting to wrap up the Launch Manager port, and as the direction and purpose of this application has changed to be a daemon - I think we need to rename it so that its purpose is clear, and to stay in tune with normal Linux naming conventions (including the package name, executable name, and source directory name). Right now, I am suggesting:
lmced (LinuxMCE daemon)
And as for any GUI front ends (that will connect via socket) that will eventually be made, we could call those lmced-client (LinuxMCE daemon client).
Just wanted to get some input before I just push such a drastic change through
lmced (LinuxMCE daemon)
And as for any GUI front ends (that will connect via socket) that will eventually be made, we could call those lmced-client (LinuxMCE daemon client).
Just wanted to get some input before I just push such a drastic change through