ESP32-C5: Espressif’s First Dual-Band Wi-Fi 6 MCU

What are your issues with MQTT+TLS in practice? If you can keep the TCP connection open then you shouldn't have too much overhead, should you?

You may want to look into the Matter standard, which already takes security into account and provides some non-certificate based security options. Such devices should integrate well with current and upcoming home automation products from tech giants like Google and Apple. Implementing it from scratch seems very very complicated, but it seems there are premade examples available for ESP32 and other such devices. As an added bonus, Matter can work over other physical protocols such as Bluetooth LE and 802.15.4 + Thread which may take some of the load of your WiFi routing.

Most IoT stuff has no random number generator anyway. Without a random number generator you can't do TLS properly.

Without that, you might as well just use HTTP and stop pretending it's secure.

There are solutions to such problems, for example by using custom CAs + cert pinning or pinning cross-signed intermediates; if the Baltimore CA signed an intermediate together with the DigiCert CA then that intermediate can be pinned and used for as long as the Baltimore CA is considered valid by the device. Implementing DANE might also be an option, negating the need for CAs entirely at the cost of extra network traffic (and angering some very dedicated internet people who detest DANE for some reason despite its usefulness in such scenarios).

The RNG problem can be solved relatively inexpensively by dedicated hardware for good enough RNGs (all you really need is enough floating voltage to seed a PRNG and it should probably work well _enough_ in practice). Because of the limited data throughput of many IoT solutions, it's quite difficult to capture enough traffic to reverse the state of the RNG compared to desktop applications where you can capture many gigabytes of data per second.

Symmetric keys also work well if you can figure out secrets management. Managing many secrets can quickly become a pain, though, so it really depends on what kind of devices you use and how many.

But yes, I think most IoT data is pretty worthless for attackers, so it can probably be sent without encryption. If you hack into my network to monitor the temperature of my room then I don't know what to tell you, there are probably better targets out there.

I don't see why a fridge should talk directly do a server. That would be a lot of fridges to reflash or more likely replace the sensor if the server changes.

If they all go to a hub, all you have to do is update the hub, plus, the hub can do stuff like local alerts.

Symmetric encryption is probably the way to go for use cases that directly connect.

I wish there was something like an IPv9 (7 and 8 are probably taken!) with 48 byte addresses and a fixed layout. 8 byte ISP identifier, 4 bytes customer, 2 bytes subnet, 2 bytes device, and 32 bytes for a public key hash.

No more certificates, no more insecure LAN connections, just IP that's always secure no matter what as long as you have the right address, and even if you change ISPs you keep the key part of the address.

How much of that code has to be resident in SRAM or XIP cache once a session key has been established to handle the common TLS record types? Is it feasible to execute the whole TLS session setup code either in place from serial flash or at least copy it to SRAM on demand allowing the application to use more SRAM once a session has been established?

The problem is, until nearly all networks support it, nobody can release a product that relies on it.

If you buy a battery powered IoT doorbell and it's box claims a battery life of 1 year, but then the battery is dead in a week because your router doesn't support the right 802.11 extensions, are you going to blame the router maker or the doorbell?

I have seen farmers using LoRaWAN, and The Things Network has pretty good availability in Europe. It's not really for smart home uses, more industrial/long range applications.

We have 10s of thousands of street lights using LoRaWAN amongst other things.

It’s very much being used! Just might not be that obvious.

I have a lorawan weather station, it's for outdoor long-range stuff

LoraWAN sort of dominates agriculture IoT (the S is for Security) market. I guess it depends on your target area, but it is alive and very well.

Even if you aren't a blockchain fan, Helium[1] is still alive and well. It is helping spread LoraWAN even further. I live in central KY and have several helium networks near me. Never in a million years did I expect blockchain to end up on farms in Central KY, but here we are.

[1] https://www.helium.com

You can do that with two wifi modems.

decreased interaction latency.

> just because there are loads of networks that does not mean there is loads of traffic.

Networks simply existing causes traffic, the beacon frames that advertise SSIDs are always transmitted at the lowest speed supported by the network, which on 2.4GHz consumer gear almost always means 1mbit/sec 802.11b. (this is the one actual real world benefit to disabling SSID broadcast, eliminating the small interruptions caused by beaconing).

Also keep in mind that 2.4GHz interference isn't just WiFi, it's also Bluetooth and decades worth of cordless phones, RF remotes, gamepads, keyboards, mice, etc.

Anyways, I use Ubiquiti gear at home, and one of the nice features it has is logging channel activity. On 2.4GHz channel 11 the utilization never goes below 25% and hits 75% regularly during peak home WiFi times. I have three smart lightbulbs and a bed on 2.4GHz at the moment, these devices have literally double digit megabytes of activity over months, so the traffic on the band isn't me.

On 5GHz channel 161 on the other hand I have three laptops, two tablets, two phones, two TVs used almost exclusively for streaming, and with all that my average channel utilization is below 10% with the spikes beyond that base level almost entirely correlates with activity of my devices.

---

I don't know what the actual real world difference is, but it's not exactly hard to make the case that moving devices to bands with shorter range and more available spectrum is a good thing for reducing the inadvertent interference caused by modern consumer tech.

OTG is used for the USB game controller(s) to the Android phone on the "driver" side. On the field, there's a second Android phone attached to the robot which receives the input from the driver side Android phone.

I can sympathize with that, but BT devices and software stacks are already out there in huge numbers. It's not even clear to me what BLE is good for, if it can't communicate with existing BT devices. USB3 at least didn't make you throw out your USB2 stuff. Is it even possible to buy a BLE keyboard, headphones, etc.? I guess some newer phones support BLE. My old one doesn't, I'm pretty sure.