Messages

1

Developers / 10.04 Web Admin Network settings: domain name and host name

« on: June 02, 2013, 08:15:24 pm »

Hi,
I just want to check I'm not missing something obvious, but I think there's a bug in the Web Admin Advanced->Network->Network Settings screen.
:-
For various historical reasons, I wanted a non-default host name and domain name for the dcerouter. This screen seems to suggest that you can change them.

Sure enough, if you change the default values of dcerouter and (from memory) LinucMCE for host and domain, they seem to change. BUT, if you reboot, they seem to revert to dcerouter and pluto respectively.

Looking into the scripts in /usr/pluto/bin, it seems that whenever changes to this page are submitted, the dhcp and named configuration areas (probably some others) are re-written.

That's not completely unreasonable given the purpose of LinuxMCE, but it would be nice to be told  .

Also, the domainname seems to be forced to the value of /etc/default/domainname. The dcerouter host name is hard coded into the network scripts.

However, some of the dhcp and named configuration files do change with changes to the network setting page.

So, in summary,

• it isn't clear that manual changes to the network configuration will be overwritten when you make *any* change through the network setting page.
• it isn't possible to get consistent settings if you change the domain name and host name though that page

I have made some minor changes to make this work consistently, but I'm not familiar enough with php and the relationship to the pluto network scripts to get everything right, but I've got what I want out of it.

If someone wants to see the changes ask me, but the reason for the post was to ask someone who knows this area if I've got the wrong end of the stick.

Andy.

2

Developers / Re: embedded Ethernet control device support in LinuxMCE

« on: March 25, 2012, 01:05:47 pm »

@tschak909

I understand. My system is coming out as a combination of DMX, MODBUS, 1-Wire and a bit of X10. The difference is the lights will still come on and the heating will work with just the Barionets running (probably off local batteries). Still controllable from any Orbiter/Media Director of course.

Most of my lighting is LED-based, and it's hard to beat a 9-channel DMX PWM LED driver for £50 (+PSU, but you need that anyway);
DMX mains dimmers can be got for £30-50;
MODBUS is for digital and analogue I/O (I have 9 zones controlled by 14 dampers with 0-10v control), LCD room controls and touch switches;
1-Wire is for the large number of temperature, pressure and flow-rate sensors in the plant room
X-10 is just for integrating a few plug-in lamps into the lighting scenes

@hari, JaseP

My mistake about the frequencies - I haven't used Z-wave because I don't think I need to in a new house. 900MHz is one of the 2G mobile frequencies in Europe, but I'm guessing it's not close enough to interfere.

Andy W.

3

Developers / Re: LinuxMCE with C#

« on: March 22, 2012, 12:29:34 pm »

Is there any mileage in compiling the C++ DCE library under managed C++ in .Net?

It would then be straightforward for C# to call managed C++.

Andy.

4

Developers / Re: embedded Ethernet control device support in LinuxMCE

« on: March 22, 2012, 10:12:18 am »

That's interesting. The only weakness of the message routing architecture that I can see is that it is hard to avoid a single point of failure.

To be honest, when I looked at LinuxMCE, the biggest quandry for me was "what do I use as the actual control bus/network?" Here are my conclusions:

Z-wave is great for retro-fit, and the mesh capabilities give it a fighting chance in real life situations (14" solid stone internal walls, that sort of thing). But it is relatively expensive to equip a whole house, and I worry that WiFi, Z-Wave, Bluetooth, Microwave ovens and so on all sharing the same space is likely to cause problems.

X10 is too slow for a whole house implementation these days. I'm surprised someone hasn't updated it with the HomePlug Ethernet-over-mains standard - I looked into it, and all the parts are there. Imagine just reaching out over the network to each auto-configured light fitting directly!

Knx/EIB is a powerful standard, but look at the price of a dimmer or a light switch. I didn't look any deeper for that reason.

Clipsal/CBus has most of the characteristics of Knx/EIB (including the price!). Nice kit, though.

DMX512 looks good as a lighting standard (fast, easy to run cables, low cost per lamp), but the whole house would depend on one PC if I used a USB or serial DMX controller on the Core. I could use Media Directors to spread the control a bit, but the DCErouter is still in the path to every lighting change.

1-Wire is capable and cheap, but sensors and controls are limited

I had been working with WebBrick Systems to try and build solution for my house, and they got a lot of things right before their unfortunate demise, but the engineer in me could see something better and more capable. That led me onto the Barionet, and MythTV led me onto LinuxMCE. I believe I have the skills to put the two together - let's see what comes out!

I just thought I'd explain this in case anyone is coming to the conclusion I'm just plain crazy (maybe it's too late ).

Andy.

5

Developers / Re: embedded Ethernet control device support in LinuxMCE

« on: March 21, 2012, 08:02:27 pm »

I hadn't heard of the MCV stuff before, and taking a look it's quite interesting. A bit of a "jump on the eco bandwagon" style of marketing, but I get the relevance.

As far as I can see, the Vera devices can't directly control much - in the same way the Core doesn't directly control much, it just controls things which do. What external hardware would you need to closed-loop control a pump on return temperature in a heat exchanger, for example?

The nice thing about the Barionet family is that it's quite capable out of the box (1-Wire, TCP/IP, RS485, RS232, direct I/O, ...), and very cheap per I/O.

I like the distributed architecture of Vera, but is the system dependent on a central portal (like the Nest) or not? I couldn't tell on a quick reading.

I'm not looking to replace anything of LinuxMCE, but I just don't like the thought of being dependent on a PC for everything in my entire house. Capable though GC100's might be, they can control precisely nothing without the Core up and running. There is no distributed control or intelligence.

The media-centric design of LinuxMCE is the right way to go IMHO, and it needs PC power to do it (or maybe ARM soon, but in any case something fairly powerful). My goal is simply to provide a "better" LinuxMCE implementation. Or more options. Or both.

Andy.

6

Developers / Re: embedded Ethernet control device support in LinuxMCE

« on: March 21, 2012, 12:43:45 pm »

I agree that anyone who pays £100k for a high-end Crestron/AMX system or whatever is going to expect annual maintenance, and probably 4-hour call out for re-programming on a whim as well, I shouldn't wonder.

And I agree that a house needs maintenance, primarily to repair wear and tear.

But I'm not convinced that mid-range home automation system with less complexity than a modern TV and a wiring system similar to a small business network needs routine maintenance.

Of course things go wrong and need changing & fixing, and many people will have limited time and knowledge to rummage around in a LinuxMCE Admin panel. Some arrangement has to be made to deal with these cases, if the householder cannot or does not want to.

That doesn't mean a system should be built out of low-MTBF components (as PCs generally are) patched up with a maintenance contract. PCs that don't have low MTBFs are expensive, because most people don't need them. That's why data centres generally use redundancy rather than high MTBF.

Paradoxically, at the high end of the HA market, you can justify all sorts of high-reliability components and architecture, which are unlikely to need replacing.

Alarms systems are an interesting example: sensors are easy to replace, the alarm systems can self-test and hardly ever fail (IME), and wiring fails pretty much only when damaged. Annual maintenance consists of running the tests and replacing batteries. They have no internal redundancy, and very simple circuitry (compared with a PC, for example). Yet the principle reason people have maintenance contracts is because insurance companies insist.

Most of the cost of a maintenance contract is the cost of attendance at site, it seems to me. If remote logging and diagnosis were simpler and more comprehensive, and DIY replacements were part of the design, I don't see what there is left for annual maintenance to do.

Andy

7

Developers / Re: embedded Ethernet control device support in LinuxMCE

« on: March 20, 2012, 07:53:15 pm »

Only just noticed this, coming back to the subject after a hiatus (building a house!).

Sorry for reanimating an old thread - it seems the most appropriate way.

I do appreciate the commercial constraints imposed by open source. I presume nobody has any objection to me selling the Barionet firmware itself, although I may just open source it in case anyone's interested (Currently it isn't LinuxMCE-specific in any way).

I suspect I'm not the only one thinking "I really enjoy this stuff. How can I make a living at it?"

Kudos of course to totallymaxed (and anyone else) who has already achieved this!

I have the Barionet supporting control algorithms, schedules and scenarios in a self-contained way.

The interface is currently HTML, and I am starting to approach the DCE interface part of the problem. Two approaches occur to me, and Id welcome any thoughts on the relative merits...

• Write a plug-in that runs on the Core, and interprets DCE messages into HTML exchanges
• Write DCE support on the Barionet itself

...I realise the latter is the obvious response, but the sheer variety of DCE messages the Barionet needs to support, and the fact that I will need to write this support in BCL (primitive Basic variant) leans me towards the former.

Also, looking at the lighting plug-in, I will have to do some similar querying of database tables to fetch things like lighting scenarios. I'm assuming that it is relatively straightforward for a plug-in to be a proxy for messages intended for multiple Barionets (or actually for lights controlled by Barionets that can have no DCE support). The same thing goes for climate and other scenarios, I assume.

At the moment, with an HTML front-end, it's a breeze to do integration/soak/stress tests. I'm not sure how easy it would be if program size constraints mean that DCE has to be the only interface!

All thoughts, comments, WTF's gratefully received

Andy.

8

Developers / Re: embedded Ethernet control device support in LinuxMCE

« on: April 28, 2011, 12:11:51 am »

so what you are doing is to move the single point of failure from a pc to an external device?
i am not in any way trying to discourage you as i would love to see more network controllable devices as well, just make sure youre doing it for the right reasons.
its is very easy to make nearly every system in a pc redundant, so that reduces the chance of single point of failure. regular scheduled maintenance can reduce that even further.

You miss the point...Since there are multiple Barionets handling different parts of the house, and they are intelligent enough to execute simple control loops and lighting scene control without intervention from the centre: there need be no single point of failure.

Also, the MTBF of a simple embedded processor is incredibly high compared with a PC. I have yet to see a motherboard that can't be crashed with a loose PCI connector or refuse to boot because the battery-backed RAM has failed prematurely.

PCs are too complicated to rely on for a whole house, IMHO. For example, I've just had to service a 2 year old mini-itx motherboard in a simple web server, because the CMOS RAM battery failed - if that was the LinuxMCE core, that would be the whole house down whatever clever redundancy I put in there.

Regular scheduled maintenance is exactly the sort of thing that should not be necessary for electronics used in home automation. Ultimately I plan to sell what I create here - how many people are going to be interested in a home automation system that requires the sort of maintenance schedule an IT data centre uses just to keep it running?

Surely the goal of home automation is to make a system that is as reliable and low-maintenance as a light-bulb: then it can go (more) mainstream and look like something other than a geek's pass time.

9

Developers / embedded Ethernet control device support in LinuxMCE

« on: March 11, 2011, 04:21:43 pm »

Hi,

I'm proposing to use embedded Ethernet control devices to do much of the legwork in my home automation system. It isn't something that LinuxMCE seems to support, but I think it should: here's my reasoning...

It strikes me one of the limitations of LinuxMCE is that the Core runs on a single PC, and is by definition a single point of failure. If that PC has a brain fart at the wrong moment, the whole house in non-functional. Not acceptable, in my book.

Nevertheless, the idea of a central system integrating security, cameras, lighting control, multimedia entertainment etc. is seductive. That's why I'm persevering.

The Barionet is a small, DIN rail device that can be commanded over TCP/IP (including SNMP, MODBUS RTU & HTTP), and has local digital I/O, and support for 1-wire devices and RS232/RS485 connected slave devices (typically more MODBUS). It also has local intelligence, programmed in a variant of Basic (ho hum!).

For those of you who haven't heard of this kind of device, details are available here...

http://www.barix.com/Overview/781

There are other, similar devices, this one for example...

http://www.h2m8.com/products/product.php?type=5&detail=1&liststyle=mainlist

...but this is the most suitable I've found so far.

My plan is that things like heating and lighting control are configured and controlled from LinuxMCE, but most of the low-level functions (lighting scenes, heating control loops) are delegated to the Barionet devices.

I think I then get the best of both Worlds - central control, distributed intelligence: resilience.

I realise this is a fair amount of work, I'm just wondering what people think of my analysis, and my plans.

Thoughts?

Cheers,
Andy.

10

Developers / Re: Specifying a pipe for a non-DCE device

« on: February 26, 2009, 04:28:07 pm »

...although thinking on it, surely it has to be a charateristic of the device template, not the individual device?

Cheers,
Andy Ward

11

Developers / Re: Specifying a pipe for a non-DCE device

« on: February 26, 2009, 04:24:31 pm »

I'll give that a go.

Cheers,
Andy Ward

12

Developers / Specifying a pipe for a non-DCE device

« on: February 13, 2009, 06:18:23 pm »

Hi guys,

Still making progress with the Dusky Control device for Sky boxen.

I have the device working, and I have the "ReceiveCommandForChild()" method picking up the fact that a Sky box is a child to the control box, and the control box DCE device has to change channels on the child Sky box.

I need to refine the templates so that I can identify the Video signal from the Sky box as an output (typically connected via a SCART lead to an input in the TV).

I can't work out how to do it. In the device template definition, the only relevant thing seems to be something like "Edit Audio/Video Attributes". And when I click on that, it tries to download IR codes, and fails. I'm not sure if it fails because there are no relevant IR codes, or if there is still a problem with the linuxmce.org service that offers these codes. Anyway it seems to be fatal to the process, and I can't get any further.

Where do I define that a non-DCE device (a set-top box) has a video output?

Again, sorry if it's obvious and I've missed it, but I've spent a frustrating few hours looking, and this is hopefully the last step.

Cheers,
Andy Ward.

13

Developers / Re: How do I get to Device data in a C++ DCE device? [Solved]

« on: February 13, 2009, 06:08:09 pm »

Thanks guys, with that bit of guidance, works a treat.

What I was missing was that just because a device reports a Block_Device parameter in the device tree, doesn't mean you can get to that parameter via an access method. The access method is only present if you add the parameter Block_Device against the device template.

Obvious now I know  .

14

Developers / Re: How do I get to Device data in a C++ DCE device?

« on: January 26, 2009, 02:27:46 pm »

Thanks guys, that's just what I need.

I'll give that a try!

Cheers,
Andy Ward.

15

Developers / How do I get to Device data in a C++ DCE device? [solved]

« on: January 23, 2009, 01:33:52 am »

Hi,

Sorry if there's a simple answer in an obvious place for this, but I couldn't find it!

I have a USB DCE device (it's the Dusky Control USB Sky device), and I have it working (Hurrah!).

...but the implementation only works with one device, because I can't translate the box_num/device_num identification system used by the Dusky software to what I need.

The solution seems to be to parse the /dev/bus/usb/nnn/mmm string that LinuxMCE generates against the Device Data/Block Device parameter when it auto-detects the device.

I've found that data in the database, but I can't work out how to get retrieve it given only the DeviceID. I could use sqlCpp and query it directly, but surely there's a utility method for doing this?

I suspect it might have something to do with ::GetConfig() and the DATA_ configuration parameters, but I can't work out the calls to make from the code.

Can anyone find it in their hearts to help me out with a simple example, please?

TIA
Andy W.