Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Yes

5 (62.5%)

No, I'll build it my self or would never use it

0 (0%)

Don't care one way or the other

3 (37.5%)

Total Members Voted: 8

[brobin]

As I mentioned I'm using an UNpowered hub so that's not an issue.

[Tuicemen]

Sorry I missed read your post.  Still I"d just go to an USB mini to regular adapter over the Hub.  The other thing you could look at setting up is a Crontab event to regularly reboot the PI. Another thing would be to set your router so the same IP is always asigned to the PI Mac address. Some routers call this port forwarding but thats not the same other refer to it as Ip reserve which is more accurate. My router has both.

[brobin]

I have "address reservation" set for the Pi so whenever the router sees a DHCP request from the Pi's MAC it will assign the same IP.  I'm going to see how the change to the Interfaces file works when I test it tonight & if there's still an issue I'll look at the chrontab option. I saw one script where it will run a ping test every 5 min and if there's no response it'll reboot.  Typically I wouldn't have the hub in place but for now it's there so I can plug in a kb & mouse while I'm still working with it. There's also a $10 item on Amazon that's a combo USB hub & Ethernet port to eliminate WiFi altogether which I don't mind since it 'lives' in my server closet.

[Tuicemen]

You might wish to look into enabling SSH then you can set things up from your PC using  Putty(SSH) to log into your pi terminal. If you realy need to see the pi destop(GUI) you can enable VNC. And log in fro your PC.

[petera]

My PiZW Alexa hub is working great (Thanks Tuice  ) except for the requirement for frequent reboots. When Alexa can't find the device I see that the Pi has gone offline and needs a reboot. I don't know enough (yet) about Pi's to know where to look for the problem and any ideas would be appreciated.  It's a Pi Zero W located within 25' of the router showing excellent signal running Raspbian Stretch (w/GUI) on a 32GB Class 10 card. Power supply is 5.1V 3A. The only things plugged into it are the power supply and the CM-19A through a 4 port unpowered OTG hub. TIA for any thoughts.

With your Pi Zero powered up and the hub plugged in type lsusb and paste the results?

Also type dmesg and paste those results too.

[brobin]

My PiZW Alexa hub is working great (Thanks Tuice  ) except for the requirement for frequent reboots. When Alexa can't find the device I see that the Pi has gone offline and needs a reboot. I don't know enough (yet) about Pi's to know where to look for the problem and any ideas would be appreciated.  It's a Pi Zero W located within 25' of the router showing excellent signal running Raspbian Stretch (w/GUI) on a 32GB Class 10 card. Power supply is 5.1V 3A. The only things plugged into it are the power supply and the CM-19A through a 4 port unpowered OTG hub. TIA for any thoughts.

With your Pi Zero powered up and the hub plugged in type lsusb and paste the results?

Also type dmesg and paste those results too.

It's a lengthy file so I've attached it rather than paste. Thanks for looking at it.  The Pi is staying connected to WiFi so far but, oddly, lights weren't responding. Both Alexa and in HA-bridge it showed commands being executed and the CM-19A LED would flicker but no X10 signal was received. Rebooting the Pi solved it but I don't know what 'it' is.

[petera]

You say the only thing you have plugged into the USB port is the X10 controller. Lsusb doesn't lie. . You have a keyboard, a trackball device and the x10 controller and of course the usb hub as can be seen from here

Bus 001 Device 003: ID 0bc7:0002 X10 Wireless Technology, Inc. Firecracker
Interface (ACPI-compliant)
Bus 001 Device 005: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 001 Device 004: ID 047d:2048 Kensington Orbit Trackball with Scroll Ring
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub

My advice from looking at your USB hub is, get another. There's a lot of cheapo Chinese USB hubs doing the rounds. They are completely hit and miss. Something like this https://www.amazon.co.uk/AmazonBasics-4-Port-Ultra-Mini-Bus-powered/dp/B003M0NURK or https://www.zdnet.com/article/hands-on-raspberry-pi-zero-3-port-usb-hub-with-ethernet/

I do suggest that you have a good search before buying Pi accessories as these boards are quite sensitive to voltage fluctuations. A pull down in voltage for any reason can easily send the board into a reboot loop

[Tuicemen]

The Pi is staying connected to WiFi so far but, oddly, lights weren't responding. Both Alexa and in HA-bridge it showed commands being executed and the CM-19A LED would flicker but no X10 signal was received. Rebooting the Pi solved it but I don't know what 'it' is.

this to me indicates something else like line noise or a power sucker.
Did the wall wart your using with your Pi come with the PI?
Where is and what are you using as an x10 transceiver?
My suspicion is the wall wart is getting hot an starts to emit noise onto the powerline.
If you have another 5volt 2 amp power supply try it.

[petera]

The Pi is staying connected to WiFi so far but, oddly, lights weren't responding. Both Alexa and in HA-bridge it showed commands being executed and the CM-19A LED would flicker but no X10 signal was received. Rebooting the Pi solved it but I don't know what 'it' is.

this to me indicates something else like line noise or a power sucker.
Did the wall wart your using with your Pi come with the PI?
Where is and what are you using as an x10 transceiver?
My suspicion is the wall wart is getting hot an starts to emit noise onto the powerline.
If you have another 5volt 2 amp power supply try it.

He already stated he was using a CM19A which is confirmed by the lsusb command.

I doubt his power supply is the issue as he has a 3ah overhead from a 5.1 volt output. He would have to test his setup under load and without load to confirm this.

Using a USB hub on the Raspberry Pi comes with its own peculiarities. That's why UDEV rules were introduced to typically bind a particular device to a particular port.

If hot plugging is working ok that would not be an issue. In the case of a hub the kernel is not seeing the device that is being hot plugged as the same device so it keeps assigning it a different COM port

This is all clearly explained here https://www.sparkfun.com/news/2332

With your system powered up and all USB devices connected unplug your CM19a and plug it back in again. Now type dmesg again and paste the output. I will be able to see what port the kernel is binding the CM19a to after a hot swap.

[Tuicemen]

The CM19 LED is blinking when a X10 command is sent from the ZeroW. This usually indicates the X10 command is being sent. This seems like (to me) the issue is not with the Zero. brobin's issue is nothing turns on/off which indicates the signal isn't getting from the CM19 to the transceiver or from the transceiver to the device.
 Since the CM19 does draw power via USB (the CM15 doesn't) it is possible it doesn't get sufficiant power to send the RF due to the Zerro over heating and only gets enough power to blink the LED though that seems unlikely.

A simple unplug and repowering the Zero shouldn't remedy the issue mediately 
A 3 amp wall wart indicates this is not made for PIs as 2 amps is recommended. Unless the specs have changed since I got mine.

If brobin was using the other ports then unplugged the devices or swapped them and this cause the X10 commands to stop working then the CM19 should not blink as the Zero would be confused as to where to send the signal.

[petera]

The CM19 LED is blinking when a X10 command is sent from the ZeroW. This usually indicates the X10 command is being sent. This seems like (to me) the issue is not with the Zero. brobin's issue is nothing turns on/off which indicates the signal isn't getting from the CM19 to the transceiver or from the transceiver to the device.
 Since the CM19 does draw power via USB (the CM15 doesn't) it is possible it doesn't get sufficiant power to send the RF due to the Zerro over heating and only gets enough power to blink the LED though that seems unlikely.

A simple unplug and repowering the Zero shouldn't remedy the issue mediately 
A 3 amp wall wart indicates this is not made for PIs as 2 amps is recommended. Unless the specs have changed since I got mine.

If brobin was using the other ports then unplugged the devices or swapped them and this cause the X10 commands to stop working then the CM19 should not blink as the Zero would be confused as to where to send the signal.

The reason I asked him to hot plug the CM19 is I don't see from the results of dmesg what COM port his CM19 is assigned to.I can find this quickly from the results of a hot swap. I'm looking for something like dev ttyUSB0 so I know what USB port the CM19a has been assigned to.

He can have as many amps over on the power supply but not under. Voltage is the important indicator. Under voltage and the Zero will power off, and over equals toast.

There's at least four issues here that could be causing the problem. One standing out at the moment is the OTG Controller driver being loaded by the kernel. It's loading as a high speed controller and then dropping back to low speed. That will cause havoc with USB devices particularly if they are high speed devices.

If you want to parse the results of the lsusb/dmesg file yourself you may be able to see something I'm not.

@brobin I imagine is not on line yet so I'm leaving it for the moment till he is.

All I'm trying to do is eliminate the obvious from the resources available before I could indicate what his actual problem is.

[petera]

@brobin just one little caveat on the CM19a controller.

I'm not sure what software you are using to test your CM19a controller. Bear in mind that Mochad doesn't fully support the full X10 command set using the CM19a controller. There is a little fiddling about that can be done to achieve this but it is not straightforward.

Just have a read up on this http://drbacchus.com/getting-your-cm19a-working-on-linux/

It's not down as supported in the XtenLib which HomeGenie relies on but it's protocol is similar to the CM15 controller so it may work.

I do not have a CM19 but must get one to test it out.

[Tuicemen]

When I thought up the Alexa Hub I designed it to use Mochad,Ha-Bridge and the CM15A. I couldn't test with the Zero W and CM19 as both of these are at my city place.
Since brobin is posting in this thread and asked for the installer, mochad woud be installed with HA-Bridge. If HG is also installed that would explain issues with sending as the drivers would conflict. Perhaps brobin could confirm what is loaded on his Zero W

[petera]

For the correct driver to load at boot the CM19a USB device Vendor ID must be correctly identified. That's what I'm trying to identify here. If not he will have to remove the offending driver manually and modprobe the correct one.

Loading the incorrect driver will give the appearance of the device working but its behaviour will be erratic.

I have to log off now but I'll check in later to see if he made any progress.

[brobin]

WOW! Thanks for all the input guys.  Let me answer as much as I can and then I'll run the dmesg again.

I have a Pi Zero W powered by a 5.1 VDC 3A power supply with a cable that has a pushbutton switch to make rebooting easy. The power supply appears to be as advertised and is not causing any offensive noise as testing from a Palmpad at the same time as the issue appeared worked fine. As petera pointed out, the extra ampacity won't hurt the pi and may be beneficial in running the CM-19A.  Photos attached. 

I have the OTG hub plugged in and, yes, the dmesg I posted shows the mouse and keyboard as I needed them to enter the commands as I haven't yet done what's needed to get into the Pi via the web. Right now going to the Pi's IP puts me on the HA-Bridge page. When not in use the KB & mouse are unplugged. I'll eliminate the OTG hub and just use an adapter once I've set up web access or can do it now for testing.  Coincidentally, I ordered the same OTG hub w/Ethernet in the ZDnet article yesterday and Amazon will deliver it tomorrow (Ya gotta love free Sunday delivery!)

The CM-19A transmits to an RR501 plugged into an early version XTBR in the same room (10' away) and there is an XTB-IIR in the house so I have no apparent signal issues. As I mentioned above, transmitting from a Palmpad worked. 

Since I modified the Interfaces file with the info I mentioned yesterday, the Pi has had no WiFi drops so I'm hoping that's solved.  Also, since I rebooted to solve the signal issue it has not reappeared.

Regarding what's loaded, I've kept it simple as I only want to use this as an Alexa hub. After installing Raspbian Stretch (full version) and letting it go through updating, I ran Tuice's hub installer which works perfectly.  The only other thing I've done is the change to the Interfaces file for the WiFi issue.  I don't need anything else as the Stargate does all the heavy lifting.  In fact, the hub is just used to send ON/OFF to unit codes on a vacant house code which the Stargate uses to trigger macros.

At is point, my thinking is that the PiZW is sending to the CM-19A because the light flickered and the RR501 is OK as it worked with the Palmpad.  My IR temperature gun shows the power supply exterior at 79F and the Pi's heatsink at 85F so overheating is an unlikely culprit.
That leaves a few possibilities; either the PiZW was sending corrupt data or the CM-19A had a problem solved by a reboot.  I wish I would have rebooted just the CM-19A first rather than rebooting both.  Sitting between the two is the OTG hub so maybe that's the culprit. If/when it happens again I'll be able to experiment further.