Building Automation under Debian: heyu, x10d, LIRC, sunwait

heyu-2.11-rc1.tar.gz from http://www.heyu.org/download/ should be a more recent implementation than http://search.cpan.org/~bbirth/ControlX10-CM11-2.09/CM11.pm to control some shutter switches and lighting over powerline.
https://groups.google.com/forum/#!topic/domuslink-users/I7LSvx8H13U tells me http://x10linux.blogspot.de/2012/08/installing-heyu-on-raspberry-pi.html can be done even for ARMv5 on Arch, but on Debian I'd need to compile (as it doesn't seem to be prepackaged), which gets stuck while trying to make the makefile already:

Quote
sh ./Configure.sh
checking build system type... Invalid configuration `armv5tel-unknown-linux-eabi': machine `armv5tel-unknown-linux' not recognized
configure: error: /bin/bash ./config.sub armv5tel-unknown-linux-eabi failed

Has anyone built (and possibly even used) heyu successfully, or any ideas for an appropriate override?



Edited 3 time(s). Last edit at 04/10/2015 03:09AM by TEN.

I have never used heyu, but I do run run a highly modified, i.e., almost completely rewritten, version of Dan Lanciani's "x10d" on my Plug and find it works quite well for me. It compiles with a simple "make x10d". It interfaces with and talks to a CM11a X10 controller (requires a USB-to-serial interface widget on the Plug). You can control X10 devices via a simple shell command from Cron, as well as from any accessible Linux machine, invoke local scripts and programs on the Plug via X10 commands, and query the status of a particular device remotely. If you're interested, you can find the source here:

http://stampfli.us/x10d.c

Unfortunately, this was viewed as a one-off project when I undertook it several decades ago, so there is no decent documentation to go along with it, but if you are interested, I could cobble together some quick notes, although it might have to wait until I get my taxes done.

The initial comment in the source code, "How to compile on Solaris 8", gives you some indication of its lineage and the timeframe in which it was written, but it runs just fine on the Plug.

@restamp,

Does the X10 interfere with other RF equipments in your environment?. I had looked at installing X10 in the past because of its cheap price, but never got around to do it. I even considered zWave and Insteon, but they are more expensive. If you had done research on these, perhaps you can give us a brief summary? Thanks.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

restamp Wrote:
-------------------------------------------------------
> I have never used heyu, but I do run run a highly
> modified, i.e., almost completely rewritten,
> version of Dan Lanciani's "x10d" on my Plug and
> find it works quite well for me. It compiles with
> a simple "make x10d". [...] I could cobble
> together some quick notes, although it might have
> to wait until I get my taxes done.

Many thanks, indeed that was from a millennium mostly missed by my search (when the processing power of a Plug was called a workstation ;)).

I hope to figure out most from the readable code, lest you draw the IRS's wrath...

Actually the apt-get install build-essential required for x10d.c also fixed the above issue with heyu (that took ages longer to compile of course).

I'll keep you posted on which one works best for me (incl. the Perl incarnation & irsend of a sampled Smart Home remote).



Edited 1 time(s). Last edit at 04/08/2015 05:47PM by TEN.

bodhi Wrote:

> Does the X10 interfere with other RF equipments in your environment?

In Europe, permissible transmit power for X10 on the mains is so limited indeed that CFL lighting, starters and switching PSUs become much of an obstacle to the signal, in particular until a (low-frequency, unlike PLC networking) phase coupler has been installed.

The newer A10 modules are said to be much more sensitive.

This should be less of an issue in the US, but the lack of returned status persists, making it hard to e.g. open blinds or windows only half way (except approximation by timing).
Any meaningful positioning precision would require an optical fork or microswitch straight on the motor axis of course, but that's not what anyone seems to build&sell, let alone integrating X10 or similar.

> I had looked at installing X10 in the past because of its cheap price,
> but never got around to do it. I even considered zWave and
> Insteon, but they are more expensive. If you had done research on these,
> perhaps you can give us a brief summary?

X10 is old and slow but does work with the above limitations.
As the solutions discussed in this thread show, the protocols are sufficiently simple to integrate with various home-brew approaches (including my own combining various remote & climate control systems through REXX).
I am not sure the newer approaches are sufficiently bidirectional (and well supported on all OSs) to justify higher price tags, but their power consumption (not negligible for always-on receivers) should be much lower.



Edited 1 time(s). Last edit at 04/08/2015 06:10PM by TEN.

Thanks TEN!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> Does the X10 interfere with other RF equipments in
> your environment?. I had looked at installing X10
> in the past because of its cheap price, but never
> got around to do it. I even considered zWave and
> Insteon, but they are more expensive. If you had
> done research on these, perhaps you can give us a
> brief summary? Thanks.

I've never had a problem with X10 causing interference. One thing to remember is that X10 is carrier-current based -- it is sent over the power lines during the point of zero crossing of the AC waveform. It is not sent over the air (like WiFi). However, lots of things tend to interfere with X10. Computer power supplies often have big capacitors sitting across the mains which can significantly degrade the X10 signal. And there is often a problem controlling a device on the other phase. (Here in the US, most houses are 2-phased.) Finally, my ham radio hobby has occasionally caused problems for my X10 devices, although on the whole they fare better than some other electronics.

I standardized on X10 years ago and have never tried anything else. Perhaps there are better systems in use today, but I've got way too much time and effort invested in X10 to willingly move onto something else at this point.

@TEN:

I'll try to post some pointers on the setup and use of x10d.c tomorrow, but right now I have to pick a friend up at the airport.

restamp,

> I've never had a problem with X10 causing
> interference. One thing to remember is that X10
> is carrier-current based -- it is sent over the
> power lines during the point of zero crossing of
> the AC waveform. It is not sent over the air
> (like WiFi). However, lots of things tend to
> interfere with X10

Ah! that's my faulty memory, of course the reversed of what I said is true, as you stated.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I posted some information about how to set up x10d and get it running on my website:

http://stampfli.us/x10/

It's a lot to assimilate in one sitting, especially if you are not already well-versed in the details from a Unix perspective. Plus, I haven't really walked through it myself, so there might be errors or subtle omissions. If you choose to try installing this program on your Plug, feel free to ask questions.

restamp Wrote:
-------------------------------------------------------
> I posted some information about how to set up x10d
> and get it running on my website:
>
> http://stampfli.us/x10/
>
> It's a lot to assimilate in one sitting,
> especially if you are not already well-versed in
> the details from a Unix perspective. Plus, I
> haven't really walked through it myself, so there
> might be errors or subtle omissions. If you
> choose to try installing this program on your
> Plug, feel free to ask questions.

Many thanks, very helpful information indeed. I compiled both x10d (very fast) and heyu (taking minutes), to migrate Home Automation of custom contriving on OS/2 REXX when the Web was young.

Actually the Plug's form factor allows for a more central location (and trying out various corners of the house in the first place) with better X10 range (at the unreasonably limited European TX power level) than the PC.
Still have to keep it while one remote control has more critical timing on the mceusb than the former serial LIRC transmitter and (possibly until I manage to bring a scope for comparison) keeps resisting my efforts including a handcrafted (synthetic from the reversed protocol) lircd.conf rather than raw_codes.

One of the things I thought I wouldn't have to implement this time around was the sunrise equation (which I also use with elevated horizons at 25.3-28.5 degrees for the "heat shield" i.e. shading control):
http://sourceforge.net/projects/sunwait4windows/ should handle the waiting for various daylight-related events.
However I wonder if there's still something wrong about locale & friends since it doesn't seem to pick up the DST in effect for TZ=Europe/Berlin (but then there wasn't any in 115 AD):

sunwait report angle 0.5 49N 8E debug
Debug: localTimet:  Thu Apr  9 23:40:50 2015
Debug:   gmtTimet:  Thu Apr  9 22:40:50 2015
Debug: Target local-time adjust from GMT: -3600.000000 seconds.
Debug: All output to use local timezone (nogmt).
Debug: Target  year set to: 115
Debug: Target   mon set to: 3
Debug: Target  mday set to: 9
Debug: Current time    (nowTimet localtime) is: Thu Apr  9 23:40:50 2015
Debug: Target  time (targetTimet localtime) is: Thu Apr  9 01:00:00 2015
Debug: Co-ordinates - Latitude:  49.000000N
Debug: Co-ordinates - Longitude: 8.000000E
Debug: User specified twilight angle (degrees): 0.500000
Debug: User specified offset (hours): 0.000000
Debug: Function - Report

        Current Date and Time: 09-Apr-2015, 23:40:50 local-time


Target Information ...

                     Location:  49.000000N,   8.000000E
                         Date: 09-Mar-2015
     Sun directly north/south: 12:28
               Twilight angle:  0.50 degrees (custom angle)
            Day with twilight: 06:01 to 18:56

General Information ...

 Times ...           Daylight: 05:51 to 19:06
          with Civil twilight: 05:20 to 19:37
       with Nautical twilight: 04:41 to 20:16
   with Astronomical twilight: 03:59 to 20:58

 Duration ...      Day length: 13:15 hours
          with civil twilight: 14:17 hours (twilight: 00:30 hours)
       with nautical twilight: 15:35 hours (twilight: 00:39 hours)
   with astronomical twilight: 16:59 hours (twilight: 00:42 hours)

Am I omitting some export (set-ting) or should sunwait.cpp be changed to handle DST (7200 rather than 3600 seconds ahead of UTC) ?