AVATTO GW40-MQTT Zigbee-Gateway

[RichardBeisser]

Hello,

I bought this Zigbee-Gateway:
https://www.aliexpress.com/item/1005009682744839.html

As you can see, it is not a Sonoff-Device.
The device has a ESP8266 wifi-module and a EFR32MG21 zigbee-modul.

The device was delivered with "Tasmota 14.1.0 (zbbridge) by Theo Arends":

Although it appears to be a Tasmota image based on zbbridge, the tasmota-zbbridge.bin from Tasmota v15.0.1 Sharon doesn't work.

After entering the Wi-Fi SSID and password, it connects briefly. After about 10 seconds, it starts in AP mode.

I couldn't find anything about "Based on Tasmot ZB2MQ(2)" in either the tasmota-zbbridge.bin, tasmota.bin, or the documentation.

The documentation only contains references to Sonoff devices.

I have three questions:

• Which firmware file is the correct one for the EFR32MG21 so that Zigbee2MQTT also works via Ember? ezsb is no longer available.

• Which Tasmota image do I need for this device?

• Which modules do I need to include when compiling my own Tasmota image to get this "Tasmot ZB2MQ(2)"?

[sfromis]

They decided to ship with a custom build of Tasmota, using a setup unavailable in the standard Tasmota project. Maybe it would be feasible to set up a regular Tasmota template covering the config, and then test.

As I don't know details of that piece of hardware, I can't say for sure if there could be other reasons than gpio config for them to ship with their own build, hence me using the word "maybe" above.

When trying with the precompiled tasmota-zbbridge.bin, what exact config did you use? And details (symptoms and logs) might be interesting, as merely saying "doesn't work" is really useless.

Still, if it works with factory firmware, I'd suggest just staying with that, as there's no recommendation to update to latest version, unless you have very specific reasons.

[RichardBeisser]

but said nothing about exact details from when you tried to replace Zigbee chip firmware.

What details do you need?

Note that if you already have a 7.x.x version

???
As I wrote, GUI says "Zigbee: EZSP v6.7.13.0"

[sfromis]

Details are exact steps of what you did, and how current configuration is when you tried.

About 7.x.x, I very directly stated "This should not apply to you currently". And you still seem confused. But really, it should not apply to you.

[RichardBeisser]

Details are exact steps of what you did, and how current configuration is when you tried.

Here the exact steps:

[sfromis]

Steps include what you did to get that file. While it may seem surprising, it is not uncommon that people download from Github the wrong way. This includes things like right-click and download, instead of only left-clicking on relevant links.

Check file size, ncp-uart-sw-7.4.5.0_115200.ota should be exactly 235580 bytes.

[RichardBeisser]

Steps include what you did to get that file. While it may seem surprising, it is not uncommon that people download from Github the wrong way. This includes things like right-click and download, instead of only left-clicking on relevant links.

Check file size, ncp-uart-sw-7.4.5.0_115200.ota should be exactly 235580 bytes.

steps to get get file, filesize:

[gfdsa]

Oh, I see now, thanks @sfromis , I've missed the part about only relaying between zigbee chip and z2m.
Yeah, that "not enough space" comes from trying to update tasmota through the web interface to the latest release of tasmota-zbbridge. Which, as you said, want change anything in the exchange between z2m and the zigbee chip.

[RichardBeisser]

With "Flash Size 1024 KB" (from a screenshot in the first post), unfortunately there is no precompiled build matching that strange hardware config. Devices with a ESP-12 module typically have it with the normal 4 MB of flash, but with only 1 MB, you'd need a custom Tasmota build.

That's a good keyword.

If I'm interpreting the screenshot correctly, then "flash size" means the memory in which Tasmota is stored, i.e., non-volatile memory, like a hard drive.

Is "Free Program Space" the main memory, i.e., RAM?

In order for Tasmota to be flashed onto an ESP chip, the "Flash Size" value must be larger than the "File Size" value:

Is that correct?

This means that every precompiled Tasmota binary fits every ESP32. There's no *.bin file larger than 1MB. As far as I know, every ESP has at least 1MB of flash memory.

[sfromis]

The story is different and not straightforward. While "Flash Size" is indeed the available non-volatile memory, that "Free Program Space" you see is indeed confusing. Here's what I see with a standard Tasmota build on a device with only 1 MB of flash:

Now "Free Program Space" makes sense - when adding it to "Program Size", you get close to the available "Flash Size" (settings data is the difference). And "Free Memory" is available RAM.

What complicates the situation is that in addition to the file size, each Tasmota build has a memory model which becomes minimum "Flash Size" for normal operation. The precompiled `tasmota-zbbridge" build has a memory model for 2 MB of flash on ESP8266. That's why it is not suitable for your device.

Your screenshot shows that things are messed up, not sure exactly how that was done, maybe "some genius" thought that it was a good plan to just ignore the requirements, and force-flash a zbbridge build requiring 2 MB of flash to a 1 MB flash chip, precluding normal operation, with wired flashing becoming the only way of replacing the Tasmota build.

When it comes to ESP8266 vs ESP32, Tasmota has separate builds for the newer chip architecture, all names starting with "tasmota32" instead of "tasmota" https://ota.tasmota.com/tasmota32/release/ - and builds needs to match the hardware. This is not about available flash, but about needing a build to match the different chip architecture.

[RichardBeisser]

Am I right in saying that the "Program Size" is the size of the Tasmota binary, i.e. what is in the highlighted column:

Your screenshot shows that things are messed up, not sure exactly how that was done, maybe "some genius" thought that it was a good plan to just ignore the requirements, and force-flash a zbbridge build requiring 2 MB of flash to a 1 MB flash chip, precluding normal operation, with wired flashing becoming the only way of replacing the Tasmota build.

I thought Tasmota would calculate the "Free Program Space" value, so
"program flash size" - "program size" = "Free Program Space"
How could that result in a larger number than the amount of flash memory installed?

The tasmota-zbbridge.bin is only available for the ESP8266, not for the ESP32.
For the ESP32, there would only be tasmota32-zbbrdgpro.bin.

So you can't really use the wrong version.

Where can I find the information that the tasmota-zbbridge.bin always assumes 2MB of flash memory is available? This information is missing from the build download page.
There's a special tasmota-4M.bin for devices with 4MB of memory. It should then be called tasmota-zbbridge-2M.bin.

[sfromis]

The wrongness I meant was not about ESP32 vs ESP8266, but the fact that the standard precompiled tasmota-zbbridge.bin.gz is for a 2 MB memory model, making it incompatible/wrong if/when you have a module with only 1 MB of flash. My speculation is that they just flashed such a build to an unsuitable device. They should be spanked ✋

Normally you are right about the program size calculation, but this is thrown off by "some genius" not flashing an appropriate binary. Hence, numbers may no longer make sense.

The requirement for 2 MB of flash is implied by the build being for a specific device (from Sonoff). While it is not meant for any other hardware (except if compatible), it should be usable with at least 2MB of flash, and typical dev boards for ESP8266 will have 4 MB.

What you get with tasmota-4M.bin.gz is extra features (like a file system with upload/download) not a required build with 4 MB of flash, the standard setup for 1 MB of flash works fine too. In general, builds are not named after flash requirement, but the 4M build is just not suitable with typical ESP8266 only having 1 MB.

[h33ted]

As a parenthesis, I am not aware of a way to backup the existing firmware on the device, but I would greatly appreciate someone doing so. I accidentally pressed upgrade in the UI while looking if it was pointed to a different web server and I am now stuck on dysfunctional 15.1.0. Is there a way to dump the fw in a matter that is flashable on my device?

[HofeBY2]

I know it's not a Tasmota device, but it might be a quick way to integrate a Matter Gateway, Bluetooth Gateway, or Zigbee Gateway via Wi-Fi with, for example, Home Assistant.

Flashing it with Tasmota would certainly be possible, but not the best approach, since Shelly offers significantly more functionality.

Since Bluetooth and Zigbee gateways can't run simultaneously on the same device, I'll install one with Bluetooth and one with Zigbee.

I find the Gen4 devices interesting: https://www.shelly.com/de/collections/all-products
Shelly 1 Gen4
Shelly 1PM Gen4
Shelly 2PM Gen4
Shelly 1 Mini Gen4
Shelly 1PM Mini Gen4
Shelly 1EM Mini Gen4

Here's an article about the new Gen4 devices based on ESP32C6 :
https://youtu.be/uLH7UzsG0ic

Regards
HofeBY

[sfromis]

Beware that when commercial devices are supporting Matter, they are required to be locked against tampering, meaning that flashing Tasmota should not be expected to work.