installed, seems to run but no final stage #2
Comments
|
Looking a bit further and all of these lights are no showing as offline in the app except for three. confirmed put the bulbs back in pairing mode and the app re-added them as the same devices. Phew! |
|
Thanks so much for the detailed report.
I hadn't considered people might already be running an MQTT broker on the same machine, what I could do is detect that situation and connect as a client instead of spinning up Mosca.
This output is from the create_ap script, looks like it successfully connected to the devices but then they disconnected for some reason. I was having similar issues at one point, let me see if I can reproduce that today. I'm assuming there wasn't any output between reported from MockTuyaApi? Should have had output showing the devices requesting upgrades at this point.
Shouldn't make too much of a difference. With an unlinked device, the mock cloud will issue its own keys and so will be able to fully decrypt messages from the device. If you have keys for your existing devices, you can add them to device-info.js and you'll get the same effect. But either way, for the purpose of firmware upgrades you don't need to know any encryption keys.
Glad you were able to recover your devices. It's likely that they were still trying to connect to the mock AP. I could add a recovery script to move the devices back to your regular network if the process fails or user cancels.
Did the device in pairing mode stop blinking? I'm assuming you did not see any output from MockTuyaApi |
That's correct it just kept looping between connecting and disconnecting.
No it didn't seem to find that device at all. Per your comment on the other issue:
I think my devices (bulbs) are examples of this and wonder if that's why nothing was happening with your script after they connected? |
|
Thanks again for your time and patience, your input is really valuable for proofing this software.
Very well may be, but you should still see some output from MockTuyaApi, such as some calls to s.gw.dev.timer.count etc, so I believe the blocking issue here is with maintaining connection to our mock AP. Once we can establish that your device is connecting to the mock AP, we can add a routine to the script that sends the MQTT upgrade command. I've got some time tonight so I'm going to try incorporating all this new information and automating more of the workflow. |
|
Awesome. |
|
If you'd like to try again, I've added an MQTT upgrade command to the routine. I was able to get some stubborn devices to finally flash using this. I believe this should fix the issue folks have been having with stalling on "s.gw.dev.timer.count" etc. Note that you will need the device's secKey and localKey added to lib/config.js OR put the device in pairing mode and allow the mock cloud to link and issue it's own keys. As far as maintaining connect to the mock AP, I believe the issue could be DNS related. If the device was already online before the script runs, it may have already resolved to the real API endpoint. In theory I should be able to catch all outgoing requests but for now I'm only intercepting calls to the .tuya.com domains. As a temporary workaround you might try power cycling the device to force it to resolve again, OR by putting the device in pairing mode to initialize from scratch. |
|
Great! I try and give this a go tonight and let you know! |
|
Just looking at the config.js file, do I just replace the defaultSecKey and defaultLocalKey with the ones for the device? |
|
That's my mistake, I forgot to update the example config. I just pushed an updated example, you can add the devices' keys as a map with the device's gwId as the key and the encryption key as the value. |
|
However if it's just one device, there's no harm in putting the keys in defaultSecKey and defaultLocalKey |
|
I tried tonight two different approaches tonight. With a bulb that was already paired after entering the keys. I ran the script and the bulb did flash briefly but nothing else seemed to happen. Afterwards, as before I had to re-initialize the bulb in the tuya app. |
|
Try running the command as sudo |
|
Sorry the linking process didn't work for you. It's still pretty flaky, I have to run it a couple times for it to connect for me too. I'm going to be rewriting it soon taking into account new capture data and provide better timing. Tricky as node's event scheduling is not that high resolution or accuracy. Might be easier to extern that to C so I can do a proper usleep without blocking node. You shouldn't need to run the script with sudo as it uses sudo where necessary already. Can you confirm that an AP is being generated and you can connect to it with other devices? Try looking for a network while running If that works, try If all that works, I'm thinking that the device has cached the DNS. Did you try power cycling the device after it connected to the mock cloud? This should clear the cache and it will reconnect to the mock AP when it restarts (which is why you might have had to reprovision it in order to use it again). |
I think I got everything figured out tonight. I had mosquitto running already which was causing this to crash.
Now after that things are looking promising:
Configuration file: /tmp/create_ap.wlan0.conf.kGk16Svp/hostapd.conf
Failed to create interface mon.wlan0: -95 (Operation not supported)
wlan0: Could not connect to kernel driver
Using interface wlan0 with hwaddr b8:27:eb:ab:4a:16 and ssid "tuya_mdev_test"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
[INFO] [1/14/2019, 7:21:24 PM] MockTuyaCloud: prompting unlinked devices to connect to the network
[INFO] [1/14/2019, 7:21:24 PM] MockTuyaApi: server started on 192.168.12.1 port 80
[INFO] [1/14/2019, 7:21:25 PM] MockTuyaCloud: found device 57074320807d3a3aceba at 192.168.1.10
[INFO] [1/14/2019, 7:21:25 PM] MockTuyaCloud: moving 57074320807d3a3aceba to tuya_mdev_test
and then it found ALL of my tuya devices: then
wlan0: STA 80:7d:3a:3a:ce:ba IEEE 802.11: associated
wlan0: AP-STA-CONNECTED 80:7d:3a:3a:ce:ba
wlan0: STA 80:7d:3a:3a:ce:ba RADIUS: starting accounting session 5C3D5FBE-00000000
wlan0: STA 80:7d:3a:3a:ce:ba WPA: pairwise key handshake completed (WPA)
wlan0: STA 80:7d:3a:3a:ce:ba WPA: group key handshake completed (WPA)
After going through that with all of my devices:
wlan0: STA 80:7d:3a:3a:ce:ba IEEE 802.11: disassociated
wlan0: AP-STA-DISCONNECTED 80:7d:3a:3a:ce:ba
wlan0: STA 80:7d:3a:3a:ce:ba IEEE 802.11: disassociated
and then it loops back through the second section again. I panicked a little wondering if I had to reset up all of my lights but when I quit nothing had changed with the bulbs at all and there was no final stage AP's
Is it best to use a non-setup light?
The text was updated successfully, but these errors were encountered: