Cloud-Compatible Wi-Fi Module from STMicroelectronics Simplifies and Secures IoT and M2M Applications. Priced low, found prices already for 8.93 @ 1020 pieces
The SPWF04 Wi-Fi module integrates an ARM® Cortex®-M4 STM32 microcontroller with 2MB on-chip Flash and 256Kbyte RAM. And more of course … read all about it at the ST site.
[url]404 Error Page - STMicroelectronics
Also available as a click module : [url]https://shop.mikroe.com/click/wireless-connectivity/wifi-4[/url]
A netmf driver is in progress.
@ mcalsyn - Sorry Martin but this one is just announced yesterday and does not need anything else than power …
… and some software of course …
@ cyberh0me - and yesw, that will be my only goal for this to have ‘native’ netmf running on it with secured wifi … room enough with its 2MB Flash and 256 KB RAM … STM32F439 on it, WPA2 (Enterprise and PSK), FOTA, TLS 1.2, RSA up to 2048, and much more …
Yes, it is quite capable on its own, and possibly could even run netmf directly, but I was using the AT protocol to talk to it because it is substantially more powerful than previous options. To me, it has value as a companion to a netmf processor because it can handle the MQTT and SSL and such.
@ .Peter. - what is NETMF? 8)
@ Gus - No comment, you should know better.
Don’t get me wrong, I think the click module idea is a great idea but $49 for a WiFi module these days when you can buy the well capable ESP8266 modules for around $3 or $10 with USB and power regulation. I have about 20 ESP8266 modules doing the home automation around my home and they are super reliable and dead easy to program (albeit without proper debugging capabilities)
And about as secure as a drunken pair of knickers at Hogmanay…
No problem for me as all devices are internal to the network. None have external access. All updates to cloud logging is from Node-red.
@ Dave McLaughlin - [quote] I have about 20 ESP8266 modules doing the home automation around my home[/quote]
Dave can you briefly outline what you have these little worker bees doing? It’s always good to spark the imagination.
What are you programming them in? I have been using Micro Python lately.
@ Dave McLaughlin - I’m sure the cost will go down with time. I think the manufacturer just wants to show what the cost ceiling would be. Having an ARM based WiFi solution means that now We could make Amazon Dash like buttons for reasonably, with existing Cerb firmwares.
Used for switching lights and sockets. Also a few with sensors for temperature, humidity and a neat LPG gas bottle weighing system to know when it runs out
I’ve been trying to document when I do stuff here. Some new stuff to come after my short vacation next week.
C/C++ via Visual Studio and the Arduino plug in. Also use Eclipse with code from Peter Scargill. (tech.scargill.net)
@ Dave McLaughlin - Thanks Dave, your tech blog looks great.
Unless you have a Faraday cage around your house, insecure wifi is … insecure.
If the devices are running custom code with limited features for simple ON/OFF control and no OS, what exactly are they going to be able to do with them?
Well, it’s always reasonable to scale your security effort to the value of the thing that you are protecting, but if someone can intercept your wifi radio signal and penetrate your wifi security (which ranges from trivial to fairly hard, depending on your choice of wifi options), then that person could either monitor the activity (read sensor values and commands being issued); or could join your network and issue new commands to your devices; or could overpower your wifi AP and take sole control of your device.
I’ll be the first to admit that this is very unlikely because the devices are a) obscure (custom) and b) low value (not much gained through penetration), but depending on wifi security alone is a fairly very weak way to secure IoT devices. At a minimum, that should be combined with SSL, and preferably with mutual authentication too (that is, your devices knows via SSL attestations that it is talking to the right service host, but does your service know that it is talking to the correct device? That requires client attestations.)
I get that this is homebrew stuff, and I have and would make the same choices you are for one-off/homebrew projects, but I didn’t want to let the original “internal == secure” assertion stand.
Personally, regardless of the level of network security I’ll never fully trust home automation when it comes to dangerous devices. I take a bit of an issue with almost every switch type device on the market today in that their APIs allow for turning things on & off. Some devices should only be able to be turned off remotely (ex. stove tops, ovens, coffee makers?, 3D printers, lasers, sharks w/ lasers, etc.). These things should only be turned on manually or in a supervised way. Same goes for electronic locks that don’t have some sort of two factor verification for unlocking.