TESTING RELEASE

[Gene]

Ok, the bug of program's widget not showing up in the modules list is now fixed too.

I just updated r372 packages in the testing folder with these fixes.

g.

[Jens]

Hi Gene,

sorry to bother you, did you have a chance to look at the extended X10 codes for shutters - it's getting summer ;-)

Many thanks

Cheers
Jens

[dani]

Hi Gene,

About problem with jkUtils - Sunset Altitude :

HG is running on RaspPI.
The client is under Linux Debian/Gnome and the browser is Google Chrome.

Cheers.
Dani

[bkenobi]

I think the latest release may have broken RF X10.  I can see the RF commands on my AHP setup, but they don't show up in the log for HG.  I'm running r372 from the test release, but it still thinks I need to update (even though that fails).  I replaced the XTenLib.dll with the one I've been testing since 4/24 and I'm still not seeing anything.

After a reboot (still using the 4/24 XTenLib.dll), I sent a single command which HG saw via RF.  It did not convert this to PLC.  After this one instance, it did not respond again to RF.  Stopping and restarting the HG service did not help.  I replaced the XTenLib.dll with the release version and restarted the service.  This did not help either.

I then unplugged the CM15A, waited a couple seconds, then plugged it back in.  The HG log dumped a number of messages about the interface being missing while it was disconnected.  When I plugged it back in, I was able to send one RF command and then nothing else, just like before.

Again, I know the command is being sent since I'm seeing it on my AHP setup.  So, something appears to be broken with the CM15 code (or the XTenLib.dll I suppose).

Let me know if I can test something to help get things working again.

[bkenobi]

I'm not sure what's going on, but it could be my CM15A having gone bad.  I haven't checked RF in a few versions, but I thought it was working in the last version.  I installed r370 and it didn't work though.  I unplugged the CM15A overnight to see if the interface needed a hard reset.  After plugging it back in, it did see the first RF command, but then nothing.  Logs showed the following.  Maybe RF has been broken for a while now?

Code: [Select]

X10 > 5D 20 60 9F 20 DF
X10 > RFCOM: 5D 20 60 9F 20 DF
2014-05-20T06:15:20.8131780-07:00       HomeAutomation.X10      RF      X10 RF Receiver Receiver.RawData        5D 20 60 9F 20 DF
2014-05-20T06:15:20.8182060-07:00       HomeAutomation.HomeGenie.Automation    145      Object reference not set to an instance of an object    Exception.StackTrace      at HomeGenie.Automation.Scripting.ScriptingInstance+<>c__DisplayClass5.<RunScript>b__0 (HomeGenie.Automation.Scripting.ModuleHelper module, HomeGenie.Data.ModuleParameter parameter) [0x00000] in <filename unknown>:0
  at HomeGenie.Service.HomeGenieService.RouteParameterChangedEvent (System.Object eventData) [0x00000] in <filename unknown>:0
X10 > 5C 00 1D
2014-05-20T06:15:21.8324150-07:00       HomeAutomation.X10      RF      X10 RF Receiver Receiver.RawData
I'll try installing an older version and see if that works.  What version was the new X10 library added?  I'll try the one just prior and that version to see if that's the issue.

[bkenobi]

It looks like the CM15A must have gotten stuck somehow.  Even though I unplugged it for several hours, it was still doing the same thing.  I moved it over to my AHP setup and it also failed to function.  I used AHP's tool to fully wipe the memory and it started working again.

I wiped HG off the RPi so I could get an older version installed and now it's not happy.  But, now that I have a working CM15A again, it looks like HG should work fine.  Is there any chance that there was a recent change in the X10 library or CM15 code that could cause the CM15A to get confused?  I've never had any issues with either my main unit or this one, but this one was used so could have been abused by previous owner.

[Gene]

In the CM15 initialize code (BuildTransceivedCodes function) there were missing two bytes at the end of the message.
This was because the program we used to sniff the USB comm was a trial and so hiding messages with more than 8 bytes.

In latest XTenLib the message is now complete:

Code: [Select]

byte b1 = (byte)(transceivedCodes >> 8);
byte b2 = (byte)(transceivedCodes);
byte[] trCommand = new byte[] { 0xbb, b1, b2, 0x05, 0x00, 0x14, 0x20, 0x28, 0x24, 0x29 };

thanks to these last two bytes, now RF security codes receive in working too.

Perhaps your CM15 was hunged by using older version of XTenLib.
At least I hope so =) I'm not experiencing the problem you reported with the new XTenLib.
Of course I've been using AHPro when sniffing, so my interface probably was already in a good state before reconnecting to HG.

I'll be taking care of speed optimization soon, but in this very moment I am carrying some other tasks.

Cheers,
g.

[bkenobi]

Sounds good.  I'll just get HG back up and running and wait for the next update to get RF back.  Thanks!

[Gene]

r372 should already work.
Download it from main files section:

https://sourceforge.net/projects/homegenie/files/

Since now you reset the CM15, give it a try  and let me know if you experience any problem.

Cheers,
g.

[bkenobi]

OK, will do.

[bkenobi]

I tried a backup installation of HG and everything seemed to work fine.  Updating to r372 now.

[Gene]

HomeGenie r373 is now available for testing.

https://sourceforge.net/projects/homegenie/files/testing/

31/05/2014 1.00 beta rev 373
   - Scheduler can now evaluate expressions with parentheses
   - Statistics now consider any value starting with "Meter." as valid for counter facility
   - Source code editor now has better formatted error messages
   - Added PullUp and PullDown resistor configuration to Raspberry GPIO and MCP23017 programs (MCP23017 PullUp only)
   - Fixed bug in Interconnections (remote modules control was working only for few minutes)
   - Fixed bug in Server Sent Events (bad IDs formatting)
   - Fixed minor bug in UpdateChecker

Testers, please download and report =)

Cheers,
g.

[bkenobi]

I just installed this, so I may find some other things.

I opened the activity log and noticed an endless stream of Scheduler errors.  It kept going and eventually caused Firefox to ask to continue running or stop the script.  Even stopping the script causes Firefox to hang and force me to kill the process.

The C# debug messages seem to be better.  Did this address the trigger versus run code issue I described in the other thread?

[Jens]

Hi Gene,

I bought just yesterday an LM12 X10 Dimmer Module for test, I am still on 372.

Level Memory PID 16 and X10 Dimmer bright PID 84 are running.
At module level the check box for level memory is ticked on also I tried
ticking the box for X10 dimmer bright.

I can control the brigness of the Dimmer w/o any problems. The strange scenario is
dim to 50%, turn off. After turning it on it starts bright (not a 100%) but the brightness is automatically decreased immedeately to maybe 25%. I think I tried all combinations
of enabling PID 16 and/or 84 and check boxes ticked on.

I am using hue lights (which are kind of dimmer, too) w/o any problems.

Am I doing something wrong? Do you have the same X10 module for test?

Thanks
Jens

[Jens]

Hi Gene,

my DHT11 went dead so I was not using it for a while. I have two boxes running now 372, both having a DHT11 connected to them. One box shall forward the measurements to the main box. The measurement notification shows up, but the value is not stored in the DB nor is the module created as a virtual module to include it e.g. in the dashboard of the main module.

This was working a while ago in previous releases.

Thanks
Cheers
Jens