[DEPRECATED] Tasmota 7.x/8.x firmware for Hubitat + Tuya, Sonoff and other drivers

What's the device?

1 Like

Sorry guys, my bad it was on the list (reminder to self: must look carefully next time :face_with_head_bandage:). All working perfectly now!

2 Likes

If you post the link to the device I'll add it to the auto config list of the new drivers when they are published.

2 Likes

Hi @markus, how's things? hope you're well.
I just bought myself a sonoff R3 basic, I followed an instruction that I've found to flash the device, but I stupidly put the tasmota-minimal.bin to flash it with.
Now, it is not connected to anything, but it is broadcasting its SSID. However once I'm connected to it, the default page for 192.168.4.1 doesn't exist for obvious reason.
is there a way to re-flash the firmware that you know of? thanks

1 Like

Through TTL no issue, but OTA is a different matter. You could try turning on and off the device multiple times. Check Fast power cycle on this page.
I hope that helps. Fast Power Cycle is discussed earlier in this thread as well. Not working for everyone.

1 Like

Thanks @markus, I've managed to flash it using USB. phew
so now, I've flashed it using the current tasmota-hubitat.bin like I use on the power plug.
hope that's still the correct bin file to use? (because it seems to be working as expected)
although until configure template, I can only see sonoff basic. (no specific one for R3)

2 Likes

They are basically (pun intended) the same.

If you are ever in doubt just check out the blakadder repository for the correct configuration.

2 Likes

Thanks both! @at9 & @markus

2 Likes

Hi everyone. First of all thank you so much to the creator and contributors of this wonderful project. I have successfully flashed multiple devices and am controlling them offline. I've also figured out a template for a bulb (Woox GU10) and sent it to the repository

I have an issue though and I have found the cause: on two devices, because I am an idiot and did not RTFM properly, I tried to flash with tasmota minimal as the initial flash binary, which is clearly mentioned you should not do. These devices create an AP and have DHCP running as expected but do not present a web page to load in the final binary when you connect to their AP. They are in other words semi-bricked. Is there any other way apart from hardware serial flashing to recover them? I do have a TTL to USB adapter but I don't think these devices will survive disassembly

1 Like

Have you tried reset to default? I think it’s on/off 5 times

1 Like

This is a common result of a bad flash and is easily fixed. Turn the device off. Wait ten seconds (many will argue this isnt needed but on some picky devices it helps) turn it on and then back off 3 times, and on 1 final time pretty quickly. So on-off-on-off-on-off-on
Once you have done that run tuya convert again and it should resume the flash and fix the device.

You may also be able to access the console at deviceip/cs to force another OTA update via commands or deviceip/up may allow you into the firmware page directly. If neither work then you will have to go the on-off route and reflash via tuya.

Thank you both for your suggestions! I will try this when I get back home and update you on the results

1 Like

I have tried your suggestions. I had good hopes for the console or upload suggestions since I hadn't tried that before (I did already try to reset them) but they both refuse those connections. One of them is a bulb and one is a plug. Both show an AP with SSID "ESP-xxxxxx" with xxxxxx an UID and I can connect. Gateway is shown as "192.168.4.1" so that should be their IP but all connections are refused, or at least the ones I tried, HTTP (main page, /up and /cs), HTTPS (main page, /up and /cs), SSH, telnet, SCP and raw. They do refuse connections though, so they aren't unreachable, something is listening on the line and they respond to ping as well

As for the reset, I have tried all possible combinations of actions but nothing seems to work. I've been at it for 45 minutes, methodically trying every possible combination I can think of. Nothing. Added info is: the plug doesn't even show any LED activity except for half a second on boot. The light works, though only its default color of course. I have already reset the same model bulb and plug after a successful tasmota flash so I know the reset works under normal conditions. I have tried from Windows, Linux and Android to connect, same results. I wait about 1 second between switching OFF and ON when trying to reset. I still suspect I'm doing something wrong with the reset procedure or that the device has another procedure when in soft access point mode and on tasmota minimal than in normal operating mode

edit
I realize I am derailing the thread a bit. I will ask in the tasmota forums

1 Like

Ran into a bit of a problem. Flashed another tuya device (of the same type) and when I create the device in HE and hit the configure command I get this :

java.lang.IllegalArgumentException: A device with the same device network ID exists, Please use a different DNI on line 728 (configure)

I got around this by changing the preferences to use IP as Network ID which created a new DNI in place of the null value that I got when I manually added the device (they are on a separate VLAN to the HE). Now the first tasmota device I set up has null for the DNI.

Is there a way for the DNI's to come up as unique values or will I need to set the preferences on each new device?

PS: Also manually turning on/off the switch on the device doesn't change the device state which I though it should. Is it because the switch is located on a separate VLAN which has no access to the subnet where the HE sits?

1 Like

This is because all your devices share the same MAC address, choose to force use of IP as ID and you should be fine, I do need to catch that error and stay on IP when it happens though. Thank you for reporting it. Will add it to the TODO since I probably can't fix it right now.

1 Like

No problem. with my PS I edited it while you were responding. I'm guessing manually activating the switch requires the switch to be able to access the HE and not walled off in a different VLAN?

1 Like

They can be in different VLANS, if there are FW rules to allow them to talk, this is the advance use section of this... There are users like @theisgroup who are far more versed in this than I, at the very least in terms of setting it up and getting the terminology right.

1 Like

Got it. I'll set up some new rules to test. Are we only talking http communication only?

1 Like

To tasmota from the hub only TCP port 80. From Tasmota to HE it is TCP port 39501. And then for discovery SSDP UDP port 1900.

1 Like

Doh! Should have realised that from the Tasmota config page! Thanks Markus!

1 Like