I seem to recall a VMware complaint similar to this too, and there was a ring buffer tuning to do to fix it… But that error message doesn’t seem quite right to match it.

TX queue timeouts can be caused by several things, but I wonder if you’re not seeing an end result of a spammy Ethernet flow control implementation where the device can’t transmit because the link is continuously paused.

If so, there may be rx_xoff counters viewable from within proxmox, or “ethtool -s enp1s0f0” would tell you where the device is seeing pause frames from the switch on a regular Linux host.

The link down tends to be a reaction by the driver to recover from a hung queue, so if it’s not flow control, there could be a driver/firmware upgrade possible, or a series of tunables if there’s a bug somewhere in packet handling land resulting in the NIC itself hanging.

It could be a case of disproportionate impact - consider that forecasting within Haier for their cloud API would probably be based upon X number of units in the field and Y number of average API calls per unit/user/premises. At 40,000 units in the field at 1000 calls per day (which they know because they designed the software, or at least had a hand in resourcing discussions), you have 40,000,000 calls per day.

If you have some third party app which is generating 4,000,000 calls by itself, and you see only 400 users doing this, then it’s a simple high usage target to hit.

Ad revenue, maybe. Tracking is still possible because it’s the same device, and if there’s any security at all, they’ll still have all the native API stuff they’d normally get, temperatures, weather, occupancy, etc.

I will say at a brief glance at the repo for the project that there’s some calls which imply it would get the local IP for the device, and may from there be able to issue calls direct to the device. That would make me think there’s only a few calls to their cloud to establish a relationship and product info, so the disproportionate load theory, barring bugs, doesn’t hold up. While it’s been a good brain exercise, we’ll be left guessing, and hoping Haier decides to be better.

1. To think, from a business perspective, that any notable portion of their userbase bought the devices with the explicit expectation that it would work with HA would be naive. We’re hobbyists, a niche market, the less-than-1% of their market evaluations. Losing those customers while reducing whatever burden or cost they’re incurring is probably worth it.

2. HA doesn’t - but while I don’t have any Haier equipment to say, the other smart devices in my house which aren’t either esphome or tasmota don’t connect locally to my devices, but to the vendor cloud API. Ecobee, Wyze, Traeger all do that instead.

3. Totally agreed. I think AWS API costs are a few cents to the thousand, so a discussion with the developer about the use would be the nice way instead of just kowtowing to the bean counters.

I am in no way defending their behavior, but API calls will always incur some cost - either in backend resource consumption with “paying” customers, or legitimate costs if they’re relying on AWS infrastructure.

However, like the whole reddit debacle, API usage isn’t always well optimized at the client end, and it can become a negotiation rather than a C&D…unless you’re looking to make a competitor as well.

I don’t pretend to be an expert in this, and I also have no idea what the state machine looks like for unauthenticated WiFi, but my thinking on the call stack is either you were authenticated and the association with the AP dropped while sending a frame and puked, or it kicked it while attempting to authenticate to an AP, and I have no idea why a mutex would be taken, or to what, but it timed out apparently.

So why would this happen after a rebuild?

1. freak accident/timing thing.

2. I see multiple mt## modules loaded, and I’m suspecting while not looking it up that they are operating a MediaTek chip in that dongle, and are potentially conflicting.

3. lots of wifi devices I’ve seen recently have loaded firmware separately from driver from /use/lib(or lib64)/firmware and the version changed from before, and maybe needs updating now or you did it before or whatever.

I agree with others - I’d give you a fiver if it happens again without the adapter connected.

No disagreement on viability of the offspring and their subsequent ability to mate further down, only a disagreement about percentage between single digit up to “half” in the current breed (as it exists in the USA). I believe it’s notably diluted from the original cross for reasons I stated in my other reply, but I’m curious about my red since she’s considerably more dingo-esque than my blue.

Anecdotal evidence is the best evidence, right?

Right, but they’re no longer half dingo after the multitude of generations has passed in whichever pedigree, because for whichever innate temperament traits you might desire, along with the inability to selectively breed for physical ones with a wild dog, you wouldn’t take a second generation heeler and cross a dingo back in just to keep the percentage up. I don’t honestly know the whole history but it’s conceivable that enough of the original breed starters contained sufficient “dingo” to keep the content up.

I thought I had read that one of the various tests…wisdom panel maybe…was providing results indicating wild crosses, including dingo. My thinking was that any significant percentage would show, but time will tell, since we have whichever brand that was, and just need to collect and run the sample.

They are not, it’s just some breed representation thing, and they certainly look more dingoey than a Jack Russel, but at least in the United States, it’s likely to be trace amounts. Source, I own two, but admittedly neither have had any sort of genetic test so I guess my hearsay is as good as yours…I should find out, I honestly wouldn’t be surprised if they had up to a quarter dingo somehow.