Closed takigama closed 4 years ago
Please follow the template when opening a new issue, in particular I need to see logs in order to help narrow down the problem.
yes, appologies for that, went to upload the logs and realised theres alot of noise in them so im regenerating them as we speak.
unforuntatelly it doesnt seem to be creating any logs in the data volume (im using the docker one), only have the docker-compose logs
@Cyber1000 created the docker configuration. Do you have any tips on locating the log data @Cyber1000?
The docker-compose log doesn't tell me much. I can see an ESP device reconnecting, which may mean that this is a device with patched firmware, but we'll need to see the tuya-convert logs to be sure.
i actually did this from scratch and made a new docker installation... looking at the docker container though, it appears its putting the logs somewhere it wasnt supposed to originally.... the docker-compose has a mapped volume:
volumes:
- ./data/backups:/usr/bin/tuya-convert/backups
but the docker container itself shows this (inside the container):
root@graviton:/usr/bin/tuya-convert/backups# find / -name smarthack-psk.log /usr/bin/tuya-convert/scripts/smarthack-psk.log root@graviton:/usr/bin/tuya-convert/backups# ls /usr/bin/tuya-convert/scripts/smarthack-psk.log /usr/bin/tuya-convert/scripts/smarthack-psk.log root@graviton:/usr/bin/tuya-convert/backups# ls /usr/bin/tuya-convert/scripts/ eula_accepted firmware_picker.sh hostapd_ctrl psk-frontend.py setup_checks.sh smarthack-mqtt.log smarthack- udp.log smarthack-wifi.log fake-registration-server.py hostapd.conf mq_pub_15.py setup_ap.sh smartconfig smarthack-psk.log smarthack- web.log tuya-discovery.py
i've copied those files out of the docker container manually:
smarthack-mqtt.log smarthack-psk.log smarthack-udp.log smarthack-web.log smarthack-wifi.log
Sorry to be the bearer of bad news, but these are indeed patched. See #483 and the wiki for more information.
Hate to be commenting on closed issues and all that, but can you confirm if you were able to solder to the test pads and flash it manually, and if that was successful if the GPIO is the same as what is reported here https://templates.blakadder.com/mirabella_genio_I002741.html I ask because I have an older one that matches those GPIO, and also a newer one that has been patched, and they changed the physical board layout, most interestingly moving to I2C, so it would be nice to know.
Sorry a little late for me I think :-) Too much work and too less time ...
But just for clarification:
volumes:
- ./data/backups:/usr/bin/tuya-convert/backups
This backup-folder only contains the backup of the old firmware and a device_info-file. Logs weren't that important to me for longer persistence, so as you've found out, you can get them only from inside the container with some docker cp command. I'll add some tuya devices round christmas at home and hopefully update the docker-container with some improvements.
I recently purchased some of the I002741 after having previously flashed them using tuya-convert. Unfortunately the new ones (October 2020) don't work with tuya-convert.
I haven't attempted to flash them manually yet but thought it might be helpful to share a photo of the internals.
I just got a TYWE2L to flash, Ill share my headache...
The current (as of this writing) firmware from Tuya seems to make the OTA flash break do to an encryption error(version mismatch it seems to report). To flash via serial you have to pull IO0 low(attach it to ground), after it reboots IO2 becomes the serial TX. I used a DPDT(6 pin 2 position non-momentary) to flip-flop between the two modes. In one position the switch connects one pin to the normal TX and left IO0 floating, in the other it attached IO0 to the negative rail and attached IO2 to my serial cables RX line. This is a tiny, one line, easily missed hint in the Tuya documentation for that module. After attaching to the "learning mode" TX line it backed up the stock firmware and flashed the Tasmota firmware normally per the esptool.py(not esptool) instructions. I have access to the webpage and it interfaces with tasui. Unfortunately Im still lost on how to template this module. I have it on a breadboard atm with LEDs on the outputs, and I cant find a correlation between the GPIO in the webpage config and the GPIO on the module....
For the light, Just FYI its an SM2135 and it looks like this (i have what looks to be exactly the same one, thanks to some folks on the mailing list for pointing me in the right direction):
For one of my lights, i accidentally ripped the tx and IO0 test pads off mine and had to desolder the whole thing and eventually replaced the module with a ESP-01.. I got another light that is externally identical (though the badge says 3A instead of mirabella) except instead of the TYWE2L it has a WB2L which is a completely different, but pin-compatible chip... Its based on something called a BK7231T which i can find not a thing about except on the tuya website... ultimately i designed a esp-12 based board to replace it (havent actually finished this yet):
I have two devices, both mirabella genio's
First is a smart plug, they used to be exactly the same as the "brilliant smart" plugs, but they have a new model that is similar but has two usb ports and is square (only link i can find). Not actually listed on the mirabella site.
Putting it into pairing mode was no issue and it did join the vtrust AP, but as soon as tuya-convert sends magic packets, it goes out of pairing mode and back to normal. I then connected this to a tuya account just to see what would occur and since then it i've been unable to get it to join the vrtrust network since (tried resetting it, etc) - havent dismanteld it yet though.
The second device was a downlight which I have dismantled and has previously been reported as working (though 16 months ago). Its based on the TYWE2L module and it does the same thing, goes into pairing mode, soon as it sees magic packets, it drops out of it. This one is quite easy to dismantle, can get to the module and wire it up for flashing (though its a bit tough).