SolarTimes - GUI and XML not the same

Hi Folks!

New user to HomeGenie – we’re still training each other. :slight_smile: Using it on a Raspberry Pi 3B (to replace AHP on a virtual Windows XP), version v1.3-stable.19. So far using HG to control X10 devices (switches and dimmers) via CM15A.

Most controllers are working properly – I’m learning! One thing I found was the GUI and schedule.xml don’t seem to always agree with each other. (Which probably means I’m not doing something quite right and I’ll be told the correct process.) Was looking for a different problem and found in the log ““Unknown event name '@Solartimes.Sunrise’”. Right now only two devices are programmed for that and in the GUI both display Times is capitalized.

Made a backup of scheduler.xml and found it listed “Solartimes” – explains why that controller doesn’t shut off in the morning! So the question is why is the GUI showing the correct upper-cased command but the text in the XML file lower-cased? (Yes, I did .) And I won’t find out until tomorrow morning if this now works correctly.

A second question is is there a command to clear the memory in the CM15A? There is one in ActiveHome Pro and handy to do so every so often. Via command line is fine (Linux/Raspberry Pi’s OS).



If you haven’t already checked out the HG GitHub here’s a link to it. You’ll see discussions on the scheduler there. You can post that query there and let the HG author provide you with an answer.

In reply to you second question, no there is no built in utility to clear your CM15 memory. AHP or one of the Linux utilities in Mochad can be used.

Unfortunately interest in HG has fallen away somewhat over the last couple of years but luckily, for some, the X10 support is very solid.

Thanks Petediscrete! I had seen the GitHub site you recommended and it looked more like for bugs than help. I’ll look around there.


Yes, generally that’s how GitHub works but the HG GitHub doubles as a type of forum. It’s not ideal really.

There was some bug fixing carried out on the Scheduler in v14 as can be seen here. Again you’ll need to parse the bug reports Open and Closed to investigate this further. That’s certainly not ideal.

In addition, you might find that HG and your X10 modules go out of sync due to user operation. If you use HG to toggle modules it should know the correct state. However, if you control a module locally, just like with AHP, you won’t have the controller update the status as the vast majority of modules are not 2-way.

I have had a few instances of HomeGenie’s Desktop displaying the wrong
state: light/device is shown as on when off or vice versa. Usually a
logical excuse can be made – like the user (me!) playing with stuff or
there is an error in the scripting (again me). Overall seems to show

The problem I’m having with dim/level is with the coding, which is why
I’m looking for an example to follow. Yup: ‘cookbook coding’! What works
up here in my test setup doesn’t work in the real application – probably
because of differing controllers (plug-in vs. wall switch).