Bug in X-10 Firecracker Module: Module 16 won't work

Development Bug reporting
1

The Python code supporting X-10 Firecracker modules has a bug in the following line:

if unit > 0 and unit < MAX_UNIT:

Since MAX_UNIT is defined as 16, any module of any house code with the number of 16 won’t work. The code needs to change to

if unit > 0 and unit <= MAX_UNIT:

2

Could you be more specific? What HG app are you trying to use?

3

Sorry. Hopefully the following allows more clarity:

I’m using the app in Configure -> System -> Settings -> Devices and Things -> X10 Firecracker Modules. I have three widgets setup to use three X10 modules. I can control any module with the address 1 through 15. It’s not possible to control anything with 16, even though that’s a valid module number.

Looking at the code in Configure -> Automation -> Programs -> Devices and Things -> X10 Firecracker Modules (PID: 25), the Program Code tab has the following snippet:

# Add in the unit code. Ignore if bright or dim command,
# which just applies to last unit.

if unit > 0 and unit < MAX_UNIT:
   if action.upper() != 'BRT' and action.upper() != 'DIM':
   cmd = cmd | UNIT_LIST[ unit - 1 ]
else:
  print "Invalid Unit Code", unit
return

Since MAX_UNIT is defined as 16, the code will just print “Invalid Unit Code16” in the log file.

Fixing the range check to include MAX_UNIT (“if unit > 0 and unit <= MAX_UNIT:”) will allow modules with the number 16 to be used.

Hopefully that clarifies.

Thanks,

Dennis

4

Yes I’m a little puzzled as to what Python code is being referred to here. Obviously the CM11, CM15 and lately the CM19 controllers are fully supported via the MIG. The Firecracker is of course the CM17 serial to rf controller but isn’t explicitly supported in HG but has similar properties to the CM19.

Maybe as @bkenobi has pointed out you could be a bit more specific so you could be pointed in the right direction.

5

Did my response above clear anything up, or make things worse (I responded by email, and I think the email parser may have morphed some of the code syntax)?

Just fixed it.

Dennis

6

Ok.I’m a little clearer now.

If you click on this link this will show you a version of X10_Firecracker_Modules.hgx from the HomeGenie Github. How does this compare to the code you are using.Navigate down to line 210 to make the comparison. https://github.com/genielabs/homegenie-packages/blob/master/packages/Devices%20and%20Things/FireCracker%20modules/X10_Firecracker_Modules.hgx

The CM17a would not be a very popular controller used here.I’m assuming that’s what you are using to control X10 on your setup.

What version of HG are you using. Not much work has been done on this module, the last commit is quite old and do bear in mind that the CM17a does RF via 310mhz only. You could open an issue on the HG Github but I wouldn’t hold my breath on this issue being solved anytime soon. If you could resolve the issue locally on your own install that might be the best route to go.

Edit…Just found this work on the Github from the original author.Later dated but still showing the error you refer to. Again this is just for comparison purposes https://github.com/K2IE/x10-firecracker/blob/master/firecracker.py

7

I would agree with @Petediscrete in that the CM17A isn’t used all that often. That was the first controller I obtained in the starter kit I bought in ~2000 when I was in school. I couldn’t use X10 in the dorm effectively so I boxed it. When I pulled my modules back out when I bought a house it was short range and resulted in unreliable results. I tried to use it again for an attic fan controller in my current home and it still doesn’t have the range or reliability compared to PLC.

That said, my notional experience from reading forum threads on the X10 forum is that most people use the CM15A or CM19A controllers. The CM17A is maybe the 4th or 5th option but it’s mentioned so rarely I couldn’t really say. The number of people using HG over there is relatively small and I’ve never heard of anyone using HG + CM17A which leads me to believe the code hasn’t been utilized enough to be thoroughly tested. Thanks for locating the bug and please point this out to Gene by creating and issues on github. I don’t know if he will fix it, but at the very least others will be able to see your fix so they won’t be stumped!

8

I heard it referred to as a poor mans X10 rf controller. I couldn’t possibly comment for obvious reasons. I believe a lot of early Linux x10 rf exploration work was carried out using it though.

9

I’m using v1.3-stable.19 of HG.

I’ll make the change using the Program Editor to my copy, and see what happens on the next update!

Thanks,
Dennis

10

No harm reporting it on the GitHub too. That second link I gave you to the original author looks like a Python 3 ported version which won’t run in HG.

11

Done! Let’s see what happens.

Dennis

1 Like