CM15A not playing nice

[Barry-IA]

Hi Folks!

Requesting help on getting my CM15A to play nice with HomeGenie.

Hardware: RPi 4 (4 GB), 64-bit Bullseye, CM15A HomeGenie v1.4.0-beta.30

(A while back I had a question about v1.3-stable.19 not updating on my RPi 3 running Buster [32-bit]. Still won’t so I’m going with a new system. I did import the scheduler from the original system to the new.)

Issue is the CM15A controller. In ‘Settings’ it is detected as: Device Port “CM15 (USB)” Reload (with a red symbol with a slash through it above) House Codes M, N, O, P (are correct) “Device Manager” is grayed out

barry@raspberrypi:~ $ lsusb | grep -i x10 Bus 001 Device 003: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)

So seems like the CM15A is being detected just the data isn’t going anywhere. (Graphics switch from On to Off, etc.,)

From /home/homegenie/log/homegenie.log: Error System.Exception: X10 CM15Pro device not connected. (Is ‘Pro’ the same as my CM15A?)

From /home/homegenie/systemconfig.xml:

      </Interface>
      <Interface Domain="HomeAutomation.X10" IsEnabled="true" AssemblyName="MIG.HomeAutomation.dll">
        <Options>
          <Option Name="Port" Value="USB" />
          <Option Name="HouseCodes" Value="M,N,O,P" />
        </Options>
      </Interface>

(Is that .dll file right?? I’m using Linux/Bullseye.)

So what do I need to get this working? Thanks! Barry ``

[tuicemen]

CM15A is not the same animal but they do use the same driver. Did you install the prerequisites for HomeGenie as well as HG? Have you tried different USB ports on your pi?

[Barry-IA]

Hi Tuiceman! Had seens something about various CM15’s – as long as all use the same drive then is not problem. Have plugged in to various USB ports, as well as reboot between tries.

As for the prerequisites I think this may be the clue. I did this one:

To use X10 Home Automation hardware:
sudo apt-get install libusb-1.0-0 libusb-1.0-0-dev

I didn’t notice a prereq to install HomeGenie – that’s probably causing my issue. Will see if I can find, and of course would appreciate a pointer. Barry

[mralapete]

I suggest if you haven’t already copy line for line the section on Linux installation. Pay particular attention to the section on optional post installation steps https://homegenie.it/ where it states how to setup X10 and configure the serial port for HG usage.

To be honest I’m still running HG 1.3 v19 on an RPI3 and it is as steady as a rock. Still updating the OS when necessary too. If you’ve already got a working HG setup unless there’s anything particularly attractive with switching to HG 1.4 I’d stay as you are. An RPI4 in my opinion is overkill and a waste of valuable resources which are thin on the ground these days.

[Barry-IA]

Hi mralapete!

I agree the RPi 4 is overkill: the only reason I’m using it is it is faster while testing. The other/working system is on an RPi 3B running HG v1.3-stable.19. The main reason to update was a suggestion a while back 1.4 might have corrected a scheduling issue. (I have done a workaround.)

As for the optional post-installation steps, I did not do the audio ones; did the three listed under ‘X10 Home Automation’. ...Just re-rechecked and both libusb* libraries are installed. The problem seems to be lack of /dev/ttyUSB0 being created.

Might be staying with 1.3 for a while.

Barry

[mralapete]

Hi mralapete!

I agree the RPi 4 is overkill: the only reason I’m using it is it is faster while testing. The other/working system is on an RPi 3B running HG v1.3-stable.19. The main reason to update was a suggestion a while back 1.4 might have corrected a scheduling issue. (I have done a workaround.)

As for the optional post-installation steps, I did not do the audio ones; did the three listed under ‘X10 Home Automation’. ...Just re-rechecked and both libusb* libraries are installed. The problem seems to be lack of /dev/ttyUSB0 being created.

Might be staying with 1.3 for a while.

Barry

I assume you did this correctly and replaced the /path to extracted folder to the actual folder where where the zip file is located.

sudo useradd homegenie sudo cp -ar ./path-to-extracted-folder/homegenie /home/homegenie sudo chown -R homegenie:homegenie /home/homegenie

Access to the USB port requires root privileges and if you haven’t set that up properly that would explain a lot.

As I mentioned earlier unless you particularly need something in HG 14 I’d stay with what you have.

[Barry-IA]

Hi mralapete!

I think I did set the paths correctly – seems like everything is working except for seeing the CM15A. As for root privileges, might try accessing HomeGenie via Terminal, calling via sudo.

Minor setback last night: ‘updated software available’ – click, does its thing…. hmm, taking an awful long time for this step – update process locked up. My backup SD card is from earlier in the week. Oh well.

As for v1.3. vs 1.4, right now I’ll admit some of the ‘playing’ with 1.4 is to learn why the USB port isn’t communicating. Also have learned from other applications updating when having skipped two or three versions is a major headache!

Barry

[Barry-IA]

Update!

At Terminal did ‘sudo systemctl stop homegenie.service’, scooted over to /home/homegenie, then sudo ./Homegenie and things magically worked!!

/home/homegenie Permissions is Owner and Group to homegenie.

Now to figure getting the other option to use sudo.

Barry

[Barry-IA]

Hi Folks!

I’m going to post this incident here as might be part of why I need to use sudo via Terminal to get the CM15A and HomeGenie to talk to each other.

Tried updating from v1.4.0-beta.30 to v1.4.0-beta.34 using the option at Software Updates. Started via Terminal with sudo /home/homegenie/HomeGenie. On the local machine went to do the update.

Terminal capture:

2023-03-27 11:34:34.4239 Info HomeGenie.System 0 HomeGenie System HomeGenie.Status SAVING DATA 2023-03-27 11:34:34.7674 Info HomeGenie.UpdateChecker 0 HomeGenie Update Checker InstallProgress.Message = Copying new files... 2023-03-27 11:34:34.8873 Info HomeGenie.UpdateChecker 0 HomeGenie Update Checker InstallProgress.Message + Backup file '_update/oldfiles/libcoreclr.so' 2023-03-27 11:34:34.9317 Info HomeGenie.UpdateChecker 0 HomeGenie Update Checker InstallProgress.Message + Copying file 'libcoreclr.so' Bus error barry@raspberrypi:~ $

The GUI showed Installing = Copying new files

• Backup file ‘_update/oldfiles/libcoreclr.so’
• Copying file ‘libcoreclr.so’

The scroll bar just keeps scrolling.

Wait a while….Restart HomeGenie: sudo /home/homegenie/HomeGenie

barry@raspberrypi:~ $ sudo /home/homegenie/HomeGenie Failed to load /home/homegenie/libcoreclr.so, error: /home/homegenie/libcoreclr.so: file too short Segmentation fault (exits to prompt)

Copied in a backup of HomeGenie I had made this morning from the SD card; works again!

Not sure is any of this will help point to my original installation mistake.

Barry

[mralapete]

Is this all being done locally from a Terminal session on the RPI4. How well do you know the Linux file system.

[Barry-IA]

Hi mralapete!

I did write that a little confusingly, didn’t I? At this point I starting the HG session from Terminal with the command ‘sudo /home/homegenie/HomeGenie’. I then opened Chromium to access the HG GUI, to the Maintenance page, and selected Install.

As for knowledge of the Linux file system, I like to call myself an ‘advanced neophyte’: I know a lot of stuff but (obviously!) not enough. I’m willing to follow your instructions to fix or at least find out what’s wrong. If something goes wrong there’s always the back-up SD card! (smile)

Barry

[tuicemen]

Segmentation fault is a 64 bit pi issue related to memory allocation. Looks like your HG failed to update I've had more success updating from my phone then PC. I've always just reinstalled HG using the zip file and overwriting my existing HG.

[Barry-IA]

Hi Tuiceman!

OK – vaguely know what a segmentation fault is (told you I was an ‘advanced neophyte’!) – just won’t update the easy way for now (figuring whatever the problem causing will be eventually corrected). Actually re-installing isn’t that much work as long as have the scheduler and modules backed up and can click those back in.

Barry

[genemars]

Due to a bug, or rather a yet unhandled case in the new software update procedure, If a *.so file is overwritten it will cause a segmentation fault. This is likely to happen everytime some of the core libraries are updated with the new release. This issue affects hg update process on any Linux system (so even 32bit arm).

[Barry-IA]

Hi Gene!

So at least the problem isn’t something I did here. ...No idea if this is still valid but the answer at https://www.mathworks.com/matlabcentral/answers/98097-why-do-i-get-a-segmentation-fault-on-linux-when-running-an-application-that-calls-a-c-shared-library may help give the people at HomeGenie a consideration on how to get around the Linux problem. (I haven’t a clue as to what it does, just the explanation looked like it could be right or a potential lead.)

Barry

[genemars]

The problem is that *.so (native libraries) files were not a thing in HomeGenie prior to v1.4. While it's possible to overwrite and reload a *.dll library without causing any issue, doing the same with *.so files can lead to unexpected results such as segmentation fault.

The solution is to stop HomeGenie service and let an external process copy the new files and restart the service.

As this is not yet implemented in this beta, I would suggest to make a backup of hg's configuration, install the new release as it were a new install, but choosing to restore from backup file.

[mralapete]

Hi Gene!

So at least the problem isn’t something I did here. ...No idea if this is still valid but the answer at https://www.mathworks.com/matlabcentral/answers/98097-why-do-i-get-a-segmentation-fault-on-linux-when-running-an-application-that-calls-a-c-shared-library may help give the people at HomeGenie a consideration on how to get around the Linux problem. (I haven’t a clue as to what it does, just the explanation looked like it could be right or a potential lead.)

Barry

I was hoping the author would see your issue and join in. At least you now have an accurate explanation of what is occurring and not a load of guesswork. That should put you back on the right track. As I mentioned earlier I don’t use this particular version of HG so it’s good to see others attempting to test it that actually understand what they are doing and you’ve clearly highlighted a possible bug going forward. Well done.

[Barry-IA]

The problem is that *.so (native libraries) files were not a thing in HomeGenie prior to v1.4. While it's possible to overwrite and reload a *.dll library without causing any issue, doing the same with *.so files can lead to unexpected results such as segmentation fault.

The solution is to stop HomeGenie service and let an external process copy the new files and restart the service.

As this is not yet implemented in this beta, I would suggest to make a backup of hg's configuration, install the new release as it were a new install, but choosing to restore from backup file.

Hi Gene!

OK, so backed up my SD Card (RPi’s SD Card Copier) and the HG configuration file to a thumbdrive. Stopped the HG service (sudo systemctl stop homegenie.service), verified with the status option.

Followed the Quick Setup at https://homegenie.it/: wget, unzip…. Ran in Terminal: cd homegenie, ./HomeGenie

Open browser (Chromium) → http://192.168.4.125:8080 Config screen ...Restore from Backup (the thumbdrive) ...Installing with indication using the thumbdrive. Loads: oops: 2023-03-28 09:19:47.9473 Error System.Exception: X10 CM15Pro device not connected.

Exit (^C) and restart with sudo ./HomeGenie – everybody is happy again.

... For “fun” installed the update via the Software Updates GUI: v1.4-0-beta.34 to same??) Gave segmentation fault and exited from Terminal but ‘recovered’ itself: able to load from Terminal and Update Check says up to date. (Still needed ‘sudo’.)

... I did skip all of the “Recommended procedure for Linux” section with the above. Just checked: sudo useradd homegenie ==> already exists message chown ==> I am owner and group. (This installation is in a different location; the original was at /home/homegenie and this one is /home/barry/homegenie, with homegenie:homegenie. Obviously neither is quite right.)

OK, here’s possibly something: groups barry sudo dialout (etc.) No homegenie groups barry barry sudo dialout (etc.) Again no homegenie groups sudo no such user
groups homegenie homegenie dialout gpio (entire list) ...

I’m going to take a break and let you guys try to figure out my screw-up.

Thanks for the assistance!

Barry

[Barry-IA]

I was hoping the author would see your issue and join in. At least you now have an accurate explanation of what is occurring and not a load of guesswork. That should put you back on the right track. As I mentioned earlier I don’t use this particular version of HG so it’s good to see others attempting to test it that actually understand what they are doing and you’ve clearly highlighted a possible bug going forward. Well done.

Thanks mralapete!

[genemars]

Hi @Barry-IA, there's no straightforward way to grant access to an USB device to a non-root user. I haven't tested myself, but you can try the following procedure, I guess it will work:

https://elinux.org/Accessing_Devices_without_Sudo

[Barry-IA]

Hi @Barry-IA, there's no straightforward way to grant access to an USB device to a non-root user. I haven't tested myself, but you can try the following procedure, I guess it will work:

https://elinux.org/Accessing_Devices_without_Sudo

Hi Gene!

Summary: didn’t work. Did check to make sure Bullseye was using ATTRS and not SYSFS.
Copied in my raw notes should you or anyone else see anything.

Extracts from this: Step 1: Add the User to the plugdev Group groups barry Look for the group plugdev. ==> is listed. Step 2: Determine your Device's Vendor ID and Product ID barry@raspberrypi:~ $ lsusb | grep -i x10 Bus 001 Device 003: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)

Step 3: Add the Device to udev cd /etc/udev/rules.d dir 70-snap.core.rules 70-snap.remmina.rules 99-com.rules

“If you see other files, proceed with caution.” ==> That’s one of the things I like about the Raspberry Pi’s: screw something up, just swap the SD card! sudo gedit 10-my-usb.rules ==> sudo nano 10-x10_cm15a.rules (I vaguely remember it demands lower-case.)

ATTRS{idProduct}=="[VENDOR_ID]", ATTRS{idVendor}=="[PRODUCT ID]", MODE="666", GROUP="plugdev" ==>
ATTRS{idProduct}=="0bc7", ATTRS{idVendor}=="0001", MODE="666", GROUP="plugdev"

Reload with sudo udevadm trigger

cd homegenie ./HomeGenie ==> Error System.Exception: X10 CM15Pro device not connected.

Reboot.

Still getting in Terminal – 2023-03-28 11:44:39.4457 Error System.Exception: X10 CM15Pro device not connected.

Change 10-x10_cm15a.rules to 10-cm15a.rules. (filename too long?) Reload with sudo udevadm trigger

cd homegenie ./HomeGenie Error System.Exception: X10 CM15Pro device not connected. reboot Error System.Exception: X10 CM15Pro device not connected.

Recheck file – vendor and product reboot – check dmesg and /var/log/syslog for errors

reboot 12:23

barry@raspberrypi:~ $ dmesg | grep -i x10 [ 1.342479] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00000fff 64bit] [ 1.456328] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000e40000000890 [ 2.269898] usb 1-1.2: Manufacturer: X10 Wireless Technology Inc

No seeing an errors in dmesg.

syslog:

Mar 28 12:27:04 raspberrypi HomeGenie[489]: 2023-03-28 12:27:04.5130 Error System.Exception: X10 CM15Pro device not connected.

Mar 28 12:23:50 raspberrypi HomeGenie[1044]: rmmod: ERROR: Module lirc_atiusb is not currently loaded Mar 28 12:23:50 raspberrypi HomeGenie[1045]: rmmod: ERROR: Module ati_remote is not currently loaded Mar 28 12:23:50 raspberrypi HomeGenie[1046]: rmmod: ERROR: Module rc_ati_x10 is builtin.

And of course thanks again! Barry

[mralapete]

Barry I’ve seen something similar to this before. Does the vendor id of your CM15 match the one that the CM15 driver is looking for. I assume the CM15 you are using now is the one you were using in HG1.3.

[genemars]

@Barry-IA I think it should be more something like this:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bc7", ATTRS{idProduct}=="0001", MODE="0666"

you inverted vendor/product and MODE should have a leading zero.

[mralapete]

@Barry-IA I think it should be more something like this:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bc7", ATTRS{idProduct}=="0001", MODE="0666"

you inverted vendor/product and MODE should have a leading zero.

I knew there may have been a problem there. What puzzles me now is if there is in fact a problem lurking how was it not picked up on with any previous betas.

[Barry-IA]

Barry I’ve seen something similar to this before. Does the vendor id of your CM15 match the one that the CM15 driver is looking for. I assume the CM15 you are using now is the one you were using in HG1.3.

Hi mralapete!

Ooh that would be nasty!! I’m using two different CM15A controllers (for some reason I have two) and they do thev the same ID: X10 (.10) v1.3: Bus 001 Device 005: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)

Test X10 (.125) v1.4 Bus 001 Device 003: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)

Device number is different, of course, but that moves around normally. Seems like if Bus and Device was the problem rebooting would correct. I know those are different from the mfg:ID numbers (which don’t change), just sort of ‘typing out loud’.

And when I logged into post this I see Gene said I swapped the vendor:product numbers. ...Back in a bit! (Maybe a ‘byte’?!)

Barry

[mralapete]

Barry I’ve seen something similar to this before. Does the vendor id of your CM15 match the one that the CM15 driver is looking for. I assume the CM15 you are using now is the one you were using in HG1.3.

Hi mralapete!

Ooh that would be nasty!! I’m using two different CM15A controllers (for some reason I have two) and they do thev the same ID: X10 (.10) v1.3: Bus 001 Device 005: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)

Test X10 (.125) v1.4 Bus 001 Device 003: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)

Device number is different, of course, but that moves around normally. Seems like if Bus and Device was the problem rebooting would correct. I know those are different from the mfg:ID numbers (which don’t change), just sort of ‘typing out loud’.

And when I logged into post this I see Gene said I swapped the vendor:product numbers. ...Back in a bit! (Maybe a ‘byte’?!)

Barry

As I mentioned Barry I’ve seen this behaviour before but as I’m not running HG 1.4 beta it was just purely from memory.

[Barry-IA]

think it should be more something like this:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bc7", ATTRS{idProduct}=="0001", MODE="0666"

you inverted vendor/product and MODE should have a leading zero.

Hi Gene!

Told you it only looked like I knew what I was doing! (grin) Copied in your line and that removed the need for sudo at Terminal. So adding that file can be suggested for the Linux Options portion. ...Haven’t tried with the “Running as a system service” yet.

I think I’m getting a new error, or at least I don’t remember it from before: Error System.Exception: Submit Async Write Failed. Updates about every six seconds. Anyone voting for “2>/dev/null”??

Barry

[Barry-IA]

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bc7", ATTRS{idProduct}=="0001", MODE="0666"

you inverted vendor/product and MODE should have a leading zero. I knew there may have been a problem there. What puzzles me now is if there is in fact a problem lurking how was it not picked up on with any previous betas.

mralapete:

I vote to blame something changed in Bullseye! (grin) The old v1.3 system is running on a RPi 3B with Buster 32-bit and the new test system on a RPi 4B, Bullseye, 64-bit. It also seems the version of the Pi itself could make a difference occasionally.

Barry

[genemars]

That error is not good. It means maybe it got read access but not write access? Not sure. Anyway, at the following link, more clues about this matter (paragraph 4.2):

https://wiki.archlinux.org/title/udev#Tips_and_tricks

[mralapete]

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bc7", ATTRS{idProduct}=="0001", MODE="0666"

you inverted vendor/product and MODE should have a leading zero. I knew there may have been a problem there. What puzzles me now is if there is in fact a problem lurking how was it not picked up on with any previous betas.

mralapete:

I vote to blame something changed in Bullseye! (grin) The old v1.3 system is running on a RPi 3B with Buster 32-bit and the new test system on a RPi 4B, Bullseye, 64-bit. It also seems the version of the Pi itself could make a difference occasionally.

Barry

It certainly does.

Here’s a classic example of the model Pi type being very relevant. I’m not sure if it was ever addressed but I noted it was closed tonight https://github.com/genielabs/HomeGenie/issues/424

Anyway good luck with your testing. I’m sure you will get there eventually 😝

[genemars]

I just found this:

https://github.com/jfhovinne/pycm15#udev-rule

I will add a note about this to the instructions for CM15 and CM19 users.

Let me know if you sorted out the write error. Ensure there's no other software using the cm15.

[Barry-IA]

That error is not good. It means maybe it got read access but not write access? Not sure. Anyway, at the following link, more clues about this matter (paragraph 4.2): https://wiki.archlinux.org/title/udev#Tips_and_tricks

From the wiki, 4.2 section: SUBSYSTEMS=="usb", ATTRS{idVendor}=="vendor_id", ATTRS{idProduct}=="product_id", MODE="0660", TAG+="uaccess" Try adding the TAG+ phrase. And Mode change. ==> Still getting: Error System.Exception: Submit Async Write Failed. Removed (commented line). (1st time kept mode as 0666, added TAG+) same error (yes, did trigger update) (2nd time changed mode to 0660, with TAG+) same error ( “ )

Submit Async Write Failed. (Googling) Something to do with the USB device.

Well, I’ll admit stuff is soaring higher than the eagles are. I plugged in what I thought the 4.2 paragraph suggested, and yes overlooked the mode number change the first time. Neither correct, as noted. (Gene is seriously considering my 2>/dev/null joke!)

Will be back in a little while to try out more suggestions. Barry

[Barry-IA]

Let me know if you sorted out the write error. Ensure there's no other software using the cm15.

Hi Gene! Nope, nothing else using the CM15A -- is plugged in to a dedicated RPi (4 for the experimentations.) 'Stupid' questions: The CM15A is plugged into a USB3 port, just because of convenience. Theoretically not matter, right? The other quirk is I have the batteries removed: before posting I had tried things and so had the CM15A unplugged, which drained the batteries. Found out the batteries are only needed for the Real Time Clock (RTC) and in our application as a modem not needed. (I also thought the batteries allowed retaining the programming -- the USB cable could be unplugged.) Not really going anywhere with that trivia, but just in case is meaningful. Barry

[mralapete]

You need to clear the CM15 of all macros and timers from the eprom. Simple enough.

Have you tried entering su and running from root. Purely for experimental purposes.

[Barry-IA]

You need to clear the CM15 of all macros and timers from the eprom. Simple enough.

Have you tried entering su and running from root. Purely for experimental purposes.

Hi mralapete! Any suggestions how to clear the memory? I found some on-line (haven’t tried yet – rather have some verification even though the source seems reliable).

Option 1:

st -- show device status including RF security devices

echo "pl a all_lights_off" | nc localhost 1099

So I’m thinking echo "pl a all_lights_off" | nc localhost 1099 and I’ll have to check the 1099.

Option 2: Per https://www.linuxha.com/USB/cm15a.html Think was #13) Dump memory? (0xDF) If so how issue, or the command line – use echo?

As for su, think we semi-solved with the /etc/udev/rules.d file. And worked without it with sudo ./HomeGenie. Did I misunderstand your question? Barry

[mralapete]

In this link under the Hardware section it advises using ActiveHome Pro to effectively clear the eprom of all macros and timers. https://bfocht.github.io/mochad/

No I was just suggesting running HG as an experiment in the su environment to eliminate any ownership/permission issues you may be encountering.

To be honest this whole installation process needs to be fully automated and/or clearly documented as it was in HG 1.3. The curious or casual HG user will not have the patience for this and will just move on to the next home automation offering.

[Barry-IA]

In this link under the Hardware section it advises using ActiveHome Pro to effectively clear the eprom of all macros and timers. https://bfocht.github.io/mochad/

Hi mralapete!

That’s the problem: what if someone doesn’t have a working ActiveHome Pro (AHP) any longer?

As for the su environment suggestion, I’ll admit to not making a connection: I don’t use su unless specifically told to. Not in my ‘mental vocabulary’.

And as for the automated, agree. I think we’re kind of working on that: I’m the guinea pig. err, beta tester. We got the USB connection problem corrected. Don’t know if it’s something weird I did here or something in Bullseye or…. the good news is it’s been fixed and Gene indicated the fix is to be in the updated installation instructions.

BTW, speaking of the installation instructions, one thing I’m confused about is the location of HomeGenie. The initial unzip section indicates it goes to $HOME/homegenie (so here is /home/barry/homegene, a subdir to my user folder). The next set of instructions for setting up as a service indicate /home/homegenie, a subdir equal in level to the user’s. There’s probably permission difference in the two locations. FWIW I’ve had in both locations on separate SD cards – neither corrected the USB issue until added the file to /etc/udev/rules.d.

Barry

[mralapete]

There was a previous method that was used in Mochad to clear the memory but has since been removed as it caused more problems than it solved. To be honest anyone still using X10 at this stage would either have or have access to AHP to perform this one off task.

Well HG 1.4 is now at beta 34 and these difficulties are only being discovered now. I assumed Tuicemen was the head tester in all things X10 for HG 1.4 beta and he does use a CM15. Surely after testing 34 betas this problem would have been located and addressed by the tester at this stage. There has been no mention of udev rules being required until you raised it.

As I mentioned earlier my days of being a Guinea pig are done. What I did suggest was using the su environment to see if HG would run manually after stopping the service daemon and without defining udev rules. Again it’s up to you if you want to try but if it does run it would answer a number issues you are having.

My days with X10 are nearly at an end. I did quite a bit of work getting it to function correctly in the Linux world after X10 went under. It’s certainly very stable on HG1.3 v19 and to be honest it’s the last element I have running on HG. I’ve practically migrated all other home automation functions to alternative platforms.

I only dropped by to see if I could assist you on the X10 front. You have a decent knowledge of what you are doing now and between yourself and the author, if you stick with it you should get there.

Take care.

[Barry-IA]

Hi mralapete!

I’m going to miss your input. I hope I didn’t piddle you off: some of my comments may have come across as crass in text. I know some advanced stuff and am completely in the dark on some simple stuff. ...Like the ‘su’ stuff: I’ve heard of it, I’ve used it, but only when given specific instructions to follow.

On to my testing:

Stop HomeGenie: sudo systemctl stop homegenie.service Edit udev file: /etc/udev/rules.d/10-cm15a.rules – comment (#) the one line Reload udev: sudo udevadm trigger

./HomeGenie ==> loads per Terminal but can’t access via Chromium (on the same RPi) Not seeing any CM15A / USB errors, reboot ==> something’s screwy. lsusb → OK cat /etc/udev/rules.d/10-cm15a.rules commented OK cd homegenie ./HomeGenie 2023-03-29 11:05:32.1012 Error System.Exception: X10 CM15Pro device not connected. HG Webpage now loads; attempt ON of test X10 – nope (as expected).

^C to quit HG

Read and configure su.

cd to /home/barry/homegenie ./HomeGenie Not seeing any CM15A/ USB errors in Terminal but the GUI does not turn on text X10 controller.

Exit su. ./HomeGenie Now seeing the ‘CM15Pro device not connected’ errors in Terminal, and of course the web interface clicks but doesn’t turn on the test light.

sudo ./HomeGenie ==> Turning on the light via the webpage doesn’t work either (odd: that was the original work-around). Didn’t see any CM15A errors in Terminal.

reboot

...Something seems to be majorly screwed up. I can load HomeGenie’s webpage but I haven’t done the ./HomeGenie command yet. The HomeGenie service is running (systemctl status) – and giving me the CM15A error (the udevadm file is still commented). I don’t think autoload/autostart/whatever is activated so this is not making sense to me. Should I start over with a fresh SD card??

Barry

[mralapete]

I recommend you start fresh and follow the author’s instructions for installing HG1.4. As soon as that is completed and with the service daemon in place and running, unplug and plug back in the CM15, go straight to Terminal and run dmesg and post the last 20 lines or so. Also post the output for lsusb too.

[mralapete]

While you’re doing that I recommend reading this article on udev rules. It’s a clear explanation of what can be done and how to do it. https://wiki.archlinux.org/title/udev

[Barry-IA]

Hi Folks! Not ignoring you, just busy. With the new SD card and HG installation would it be better/less confusing to create a new thread? If so I will add a reference to it here so people can track down the follow-up part. Barry

[Barry-IA]

Hi Gene!

I’ve got a learning question about the added section in the installation instructions. The information at https://elinux.org/Accessing_Devices_without_Sudo said to use a low number (like 10) so will be looked at first (paraphrasing). You’re using the number 98; I’m guessing so if the system sticks in a USB rule our addition will override it??

Tnx! Barry

[Barry-IA]

Hi Gene, mralapete, whomever is out there…..

Created a new SD card with Bullseye 64-bit on a Raspberry Pi 4 (4GB). Yes, overkill as noted previously but faster for installing/testing.

Installed homegenie_1.4.0-beta.36_linux-arm64.zip (was 34 last night: Gene’s been busy!). UnZIPs to /home/barry/homegenie.

Now from this point I’m going to give you folks a slight headache as I’m not strictly following instructions. I’m sort of experimenting to see where the CM15A (CM15Pro) error pops up as well as thinking somewhat like a person who has not installed HG before (so sort of verifying mralapete’s manual update suggestion).

At “Running in Terminal”. cd homegenie (so I’m at /home/barry/homegenie) ./HomeGenie

Loads fine, I don’t see any errors (in Terminal).

At this point I skip the “Running as a System Service” section: at this point I do not want HG to autostart as I’m experimenting plus have the old system running (on a different RPi and accidentally running both HG’s does weird things to lights with dim commands!).

So at “Accessing the UI”: http://192.168.x.x:80 – doesn’t like. http://192.168.x.x:8080 - works. Also watching Terminal: no errors noted. Did see “Content root path: /home/barry/homegenie”. (Note this is different from if I had continued with the “Running as System Service” instructions.)

Am at the webpage’s Configuration screen. Default > untic demo, tic GPIO (for my later usage),tic X10. Terminal now giving me errors re: libusb-1.0-0; back out of Config and exit HomeGenie (^C).

Install libusb-1.0-0 – which is part of the “Enabling CM15…” section. (My college proofreading job kicking in with the suggestion to move that section up.)

Re-start ./HomeGenie and Configuration. See “Error X10 CM15Pro not connected” at Terminal. Know what that needs!! Insert the 98-cm15_cm19.rules file. Unplug and re-plug the USB cable. (And I’m going to suggest be more specific here: unplug the USB cable [vs. the unit from the wall outlet].)

Still seeing the error message so reboot. Oddly still seeing so sudo useradd homegenie (one of the steps in the skipped “Running as a System Service”). Nope.

Reload udev? sudo udevamd trigger . Still getting the CM15Pro error.

Edit 98-cm15_cm19.rules : change Group from homegenie to barry (would $USER work? Would be wrong when running the service.) Unplug/re-plug. Now not seeing errors: yay!!

Install Schedules from the original X10 (the other RPi running v1.3, not a backup from prior v1.4 experiments). → Backup and Restore > Restore ==> successful.

Need to manually install widgets. I had to exit HomeGenie (^C) and restart HG for them to initialize. Common procedure, but maybe put in the instructions.

Oh: almost forgot: It Works! Wo-hoo! Or at least the initial testing: I was getting into times when the scheduling starts and not really wanting to turn off the other system quite yet. Nasty storm due in later tonight and tomorrow.

Barry

[mralapete]

Happy days. Now all you have to do is logically document your efforts and your findings. As I wasn’t testing this version I cannot verify your results. I’m still a little puzzled how anyone else using X10 on HG got this working and how it wasn’t flagged until now. The main thing is your CM15 is doing its job correctly.

[Barry-IA]

I’m still a little puzzled how anyone else using X10 on HG got this working and how it wasn’t flagged until now.

Hi mralapete!

As for others getting it working, perhaps the reverse of the question. (And I’m not trying to be a smart-rump.) Perhaps some others had problems, couldn’t/wouldn’t figure it out and just abandoned HomeGenie for some other option. I know I have over the years with other software.

Quirky hardware? We’ve noted I’m using an RPi 4, Bullseye 64-bit. What about the USB keyboard? I’m using an old keyboard with a USB port for a USB mouse. Yup: mouse is plugged in to the keyboard, not the RPi directly. Perhaps that ‘confuses’ something? Nothing else has, but then that ‘nothing’ has been thumbdrives and memory card adapters.

As you said, we’ve figured out the problem – and a thank you to all for that!

As for the Beeg Schtorm – due in later this morning and afternoon.

Barry

[mralapete]

Not sure how long you’ve been using HG. If it’s pre 2017 you’ll have the general sense of what HG was and is now about. I wouldn’t want to expand on this any further but suffice to say tester numbers are down quite considerably. Could be seen a positive for any current tester as you’ll have the benefit of a one to one experience with the author.

Personally I’ve only ever run server applications headless without any keyboard, mouse or monitor attached. Absolutely no need for them as you well know. All configuration can be performed remotely. Reduces the chance of power issues and in the case of USB, device conflicts. In my case I’ve one single CM19 attached to my Pi3+ for obvious reasons. All neatly tucked away out of sight and only accessed for maintenance purposes.

I think we can agree that X10 is not the draw it once was and maybe that would explain the lack of additional contributors on this particular issue.

Suffice to say the install process needs to be watertight and of course that is a matter for the author. I’ve a sneaking suspicion that any previous testing and possibly development carried out on the Pi4 was done in the Ubuntu environment and not Bullseye and those install instructions are Ubuntu centric. Again not being involved in any testing on HG1.4 this is only supposition on my behalf. Maybe you should try HG1.4 on Ubuntu to test my theory.

Anyway that’s me done now. Hopefully when you are up and running fully you’ll find something in HS1.4 that particularly appeals to you.

[Barry-IA]

Hi mralapete!

Not quite that long a HomeGenie user: my earliest (electronic) note is April of 2021. Reasoning for the switch from ActiveHome Pro was wanting to stop replying on Windows XP on the Virtual Machine (on the Ubuntu machine). Also wanting to stick with the X10 protocol as there’s a lot of hardware here: replacing would be expensive. And Insteon, the X10 ‘successor’ shut down last year IIRC. (From what I read those people area really screwed: no way to bypass the call-in verification like did for AHP.)

As for headless servers. have several here, mostly RPi’s (3 and 4). And keyboard, etc., not required; the only reason a keyboard and mouse is connected to the HG unit is it is under test and more convenient. Sometimes: actually most of the time I access remotely via Remmina.

X10’s draw – probably waning as considered ‘old technology’ and “everybody” is using WiFi, Smart-stuff (via phone and tablet). Again for me would be expensive to do the change-over. I also am not a fan of being required to connect to a site via the Internet to control something in my own home. What happens when the Internet connection fails? I’d either be in the dark or with the lights on during the day.

As for the install process, might work up something and submit. Quite frankly would be more notes for my own use and those get uploaded as a convenience to others.

OK, starting to rain out there and the weather service just issued a warning.

Barry

[mralapete]

I only mentioned about how long you were a user as the old forum definitely gives you a flavour of what HG was and what it is now. Worth a read if you haven’t already done so http://old.homegenie.club:8080/www.homegenie.it/forum/index.html

So many alternatives have arrived on the scene since with very active user bases and an accompanying forum to discuss matters. There was an attempt to establish an alternative HG forum by one former HG user but again through lack of interest it folded.

Once again if you are comfortable with HG1.4, who knows, the skies the limit. Unfortunately I think it could be quite a solitary journey of discovery. I will say from what I’ve seen you won’t be fed a load of BS once you do encounter a problem. Hopefully you keep the author on his toes too.

[Barry-IA]

Hi mralapete!

Made it through yesterday’s storms unscathed. Tornadoes in the area but none within several miles of here.

Thanks for the reminder of the access to the old HomeGenie Club – some of the Google searches indicate something of potential interest but just spins without the port.

As for alternatives and lack of interest, I can see that. I started with X10 years ago; it promised lots of potential and delivered on a few. Naturally someone took the X10 concept and made improvements – Insteon. Unfortunately not fully compatible as used 130 KHz vs 120 KHz for X10, plus some other changes. (Some compatibilities between the two did exist.) And of course now the WiFi control using the phone. (Wonder if can send a text message to the X10 server: curl http://192.168.x.xxx:8080/api/HomeAutomation.X10/P2/Control.Off ?!)

And HG 1.4…. I’ll admit to not paying attention to the listed updates. In the beginning of March I received a message from Gene indicating an issue I had had with 1.3’s Scheduler may have been corrected in 1.4. I’ll admit to not having tested that yet due to some of the ‘quirks’ I encountered.

Another thing about upgrading is the probability of corrections for security upgrades: maybe close a backdoor, etc. Yes all of my X10 is on the LAN side of things but still has wireless connectivity and perhaps someone could latch in. I’m not all that concerned but is a possibility.

As for the B.S., (chuckle). I’ll admit to learning all this stuff pretty much on my own so tons of holes, which help to get filled from other people – real-life forums and Googling (yea: I’m not the only one to have this fill-in-the-blank issue!).

Barry

[EnGamma]

I too am very interested in a solution to HG not communicating with CM15A, so I'll chime in on X10 and CM15A and HG 1.4:

I have not been able to get the CM15A communicating with HG 1.4 on an RPi3 running Bullseye that successfully ran HG 1.3.

After trying several things that all failed, I tabled CM15A troubleshooting because 1) I have some alternatives for operating my X10 so it hasn't been essential 2) I've been wrestling with other higher priority issues I have with HG 1.4 betas (lots of pain with each beta update not going well, backup restores not going well, and having to reconfigure from scratch).

I decided to re-engage on CM15A again today and came across this thread. @Barry-IA, I am very interested in what you can document from your ultimate success as to what the key fixes are from all your trial & error work.