-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Direct Connect using TAustin's RPi solution failing device registration #110
Comments
I should note that I am running a Cisco firewall between my home-automation network and the public WAN. That hasn't interfered with running other SmartThings registrations, but if there's something unusual about DirectConnect that might require my opening additional protocols or allowing incoming connections from the WAN please let me know. |
Hi @kubycsolutions , Mostly commercial product with this SDK provides method of reactive setup mode (softap) by pressing buttons on it. Thank you. |
|
Hi Kwang-Hui- to add to the above problem description, I have successfully run this on a Raspberry Pi Zero W without a problem. I suspect there may be a configuration issue here but because the mobile app and SDK error messages are not particularly helpful, we can’t figure this out. Could you please help us diagnose this? If he provides you a debug-level log, would that provide a more specific reason for the onboarding failure? |
Hi @toddaustin07 @kubycsolutions , The log indicates |
@kubycsolutions - I remember you were not using 192.168.2.1 for your AP address, but rather another address. In your latest testing, what IP address are you configuring the Pi's AP for? Is it possible to try 192.168.2.1 or is that not available? Kwang-Hui points out that the mobile app will look for x.x.x.1, so we need to make sure that is what your AP is configured to use. |
My "site" convention is 192.170.x.x. The pi is normally at 192.170.3.13; ..3. is my home-automation subnet and is where the SmartThings hub is attached. I've been setting up the Pi's access point configuration as 192.170.254.1, telling it to issue addresses in the range 192.170.254.2 thru .10. I can certainly try a 100% vanilla install and see it it's any happier. Question: How quickly should the AP be available after displaying the QR code, and how long should it remain available before timing out and restoring my "normal" address for the pi? I'm wondering whether I'm scanning the QR too soon. (It's definitely not too late; I've usually started trying to register immediately after the system says the example has been started, less than a minute.) |
As long as the Pi AP itself is at 192.170.254.1, then you should be OK I'd recommend re-reading the onboarding instructions in my documentation - starting on page 17. It gives you a detailed step-by-step walkthrough of the process so you can be clear on the order and timing of all the steps. Some additional things to check that are pointed out there:
Can you also share for Kwang-Hui exactly what step you are getting to on your mobile app and any messages you are seeing there? For example, if you're not eventually being presented with a list of your network SSIDs to choose from, then that says the phone never even successfully connected to the Pi's AP. |
It is failing before asking me which network SSID to connect to. I don't know whether it matters, but in the Developer's Workspace I'm defining the Direct Connect device configuration as an individual rather than Enrolling As An Organization. The screens I'm showing are slightly different from those in the document; I've been presuming that the document just referred to a previous version of the workspace but could this be where we're diverging? |
I was hoping that using
|
News: I went back and tried to run The good news is that I did get farther.
So something about the setup is depending on exact details of the instructions which I departed from previously. Possibly the AP address, possibly something else. But there's clearly a second problem once I get past that. OK, stop Example, clean up, put the phone on the home-automation access point, restart
Two things wrong with this...
So this seems to be a problem of the registration process being overly picky. I can (and will) try turning off 5GHz support in that access point temporarily and see if that lets us complete registration... but that really should not be necessary. Pi console log from that last attempt follows:
|
I'm not sure why the SmartThings code would even care what speed the device's or phone's connection to the access point runs at...? (Yes, home automation can generally be run adequately at the lower speed. But I'd really rather not have to force that in the access point, so I can take advantage of 5GHz when devices do support it.) |
As Todd said, if it would help I'm quite willing to try running with debug builds of the ST API and send you logs from that -- or turn on logging in the Android app, if that's possible and would be helpful. It's in everyone's interest to make ST device development as easy and robust as possible. |
Yes, it is true that it only supports 2.4Ghz for some reason. I never really understood why. What did you configure on the Pi that had it connecting at 5GHz? I've never done anything explicitly to affect that, that I can think of... |
Kuang Hui, I'm trying to understand what you meant when you said this:
In our case the AP itself would be at address A.B.C.1, and it would assign addresses from A.B.C.2 to A.B.C.10, for example. This is OK? |
The Pi Zero W does not support 5GHz WiFi. (Rechecked the specs.) But it is perfectly happy connecting to an access point that is configured to run at both speeds. The fact that the phone happens to be connected at 5GHz should not prevent setting up the device at 2.4GHz...? |
That's what I would think. |
So, update: I have finally been able to connect. But it's ugly.
This dance REALLY shouldn't be necessary, should it? |
My router uses the same SSID for both 2.4GHz and 5GHz. It looks as if As a workaround, I can turn off 5GHz while I register the devices. But I haven't had this problem with other devices. Are they just not asking the speed before trying to connect, or is there something else we can change so it works as expected? |
Correction: the SDK limits the return of the iot_bsp_wifi_get_freq function to 2.4GHz (not 5) |
I've been working with Todd to try to get my Raspberry Pi Zero W running as a SmartThings device, using his rpi-st-device package, following the build sequence driven by his
mastersetup
script. As far as I know, I'm operating each of the stages correctly. But when I get to the final step of actually starting the application and having the android SmartThings app try to register it, the app fails to do so and reports error code04-100
or07-003
. (I'm not sure which one I got most recently; I'll check.) I've wiped out therpi-st-device
andst-device-sdk-c
directories and restarted the build-and-register process from scratch several times, and keep failing at that same point.Todd has said that at this point he is running out of debugging ideas to try, and suggested I report the problem here and ask for assistance. Any suggestions on how we can debug this and determine what I'm doing differently from past users of Todd's code would be greatly appreciated.
The following is a console log from running
mastersetup
and selecting option 8, which should be the registration.Apologies for the terminal-coloring escape sequences; I think you should be able to read past them, but if not I can edit this down to remove them.
I am presuming that there was something following that final
iot_eas
but that it got stuck in the redirection buffers; I haven't yet explored whether there's a way of flushing those to get a more complete log.If there's a debug bit I can turn on when compiling
st-device-sdk-c
, or when running this code, I'd be glad to make that change and pull further logs. Ditto any other experiments which might help resolve this.The only thing that I know is different from past users of Todd's code is that I'm on the Raspberry Pi Zero W, which has a somewhat slower processor... and that I've usually been doing the previous stages of building the device code via
ssh
connection rather than via keyboard and screen hooked directly to the Pi. For step 8, registration, I've tried both letting the ssh connection be brought down by SoftAP and snapping the QR code from a copy kept on my laptop, and switching to actually working on the Pi's native screen and keyboard, and get the same failure either way.Presumably there is something I'm doing wrong or have out of synch, or some subtle (timing?) issue that's appearing only on the Pi Zero W. But it looks like I need deeper assistance in finding it than Todd can provide.
Help?
(Ultimate goal is for these RPis to act as IR transceivers to bring a Mitsubishi minisplit HVAC system under SmartThings control. Various pieces of this have existed, but I haven't found a complete solution so I'm homebrewing. Hopefully when I get it working it'll be clean enough to be worth sharing.)
The text was updated successfully, but these errors were encountered: