“Case Closed”
So the MK-III finally got its (3D-printed) case, now the case is closed.
Yep, case closed!
Sure the case is kinda rough (sorry, 1st time stuff there…), it still reminds me of the TARS, I don’t know why though.
Indoor Weather Station IoT – Mk III
Now it’s Mark III, having a self-designed simple carrier board with all dev kits mounted on it – seems working reliably.
室内气象采集节点，Wifi + 有线以太网两网通用，uPy固件。需要接HA的话，可以用restful sensor请求板端API，已经试过了，没毛病。这样玩的话，板子固件功能可以比esphome生成的更具自由度。
不要问我carrier board为啥选了白色，对我玩相机有印象的哥们，应该知道我备机（EOS-M3）就自己配的熊猫色，至今喜欢。
距离上次做layout，我算了一下15年有余。好在我不在乎外观，没打算从零画起，就只做了块载板。那么工作量自然也低，连原理图一起一天搞定。至于产出质量么……话说下单有点快，下完单回头review schematics发现电容接错了，又改了一版立即重新下单。
然后摩拳擦掌天天等快递，板子到手后，上电一遍过。当然一张底板，着实也是简单。
考虑到如果很多节点，server挨个请求node吧也不大合理，所以还做了个配置api地址，然后主动post数据的功能。
要问为啥不搞mqtt，呃，懒得摸新东西算个理由不？
折腾了半天，还以为想找个靠谱的asyncio http client有困难，结果还是有大佬给移植好了一版能用的。
到今天，算下来已经有三个版本了，只用业余时间，外加陪娃的话，感觉效率还凑合？
最近疫情放开，年底很多活儿堆在头上，加班免不了咯……什么时候才有精力做个壳体试试呢？
完整阅读本篇»基于RPi和LXD的ESP32开发环境
对于在板子手动重启时经常把ESP32带进下载模式的问题，LAN8720所需的上/下拉电阻恐怕是最大嫌犯。于是斥巨资近CNY 10元采购了万用板、线仔包和各种直/弯母座，终于搞了MKII —— 重启可靠性问题果然迎刃而解。
过程中，基于lxd的Debian in Debian做了套新环境，顺手也试了试C语言的esp-idf编译，用起来整体感觉很顺手。
RS232 connected with an lxc in raspberry pi 4b (not in pic)
Yes, it actually performs nicely to work on ESP32 development in debian bullseye LXD in Pi OS, no mater you’re working on hardcore C lang based esp-idf or the nice & easy micropython development.
“Hmm… so you need a standard Debian in a derived Debian? “
Well, since I found out that LXD is something very helpful to isolate different needs on different Linux distributions in different containers, while it kinda works pretty much like vm (instead of docker) since it’s easy to config the resources consumption or even usb devices pass-through, and the most important – having its own block storage which can be exported into a single archive.
Then, the only thing I can’t agree with, could be the deep connection with the snapd. Instead of switching to another distribution, such as Arch, I choose to build the LXD of my own (on both Pi OS aarch64 and Ubuntu 22.04 X86_64). Thanks to the good documentation, the stuff (native lxd without the snap crxp) works like a charm.
with Xfce and xrdp, the bullseye lxc can work as an esp dev server quite well
ESP32 + Microdot + uPy-uasyncio
基于ESP32和micropython制作的家用温湿度计原型机。可通过网页控制GPIO和OLED显示，为HA等其他服务提供访问环境传感器的实时数据API。使用uasyncio的协程实现非抢占式的异步多任务控制，估测效果应该不如基于C的RTOS，但胜在代码量小，写起来简单吧。
This ESP32 and micropython-uasyncio based indoor ambient sensors are basically working as expected, with web-controlled OLED display, and a quite simple http api for other services like home assistant to query the realtime data. The multitasking runs on non-preempt Python coroutine, which is theoretically incompetent against those C + RTOS stuff, but it wins on simplicity from my point of view, so far at least.
Hardware components：
- NodeMCU (ESP32-WROOM-32E)
- 1.3 inch OLED (SH1106, SPI/I2C, 128×64)
- BME280 sensor (ambient temperature, relative humidity, barometric pressure)
Software libs：
- Micropython 1.19.1 (for ESP32)
- Microdot (minimalistic Python web framework which supports uasyncio)
- Driver libs of all hardware components.
ESP32 + uPython + uaiohttpclient
Updated 2022-12-01: Let go this rough uaiohttpclient since it’s kind too simple (just GET, no POST, and lacking almost anything needed) to be integrated to something really useful. So currently I’m using someone’s own stuff (async mod on urequests) that works – from the REPO HERE.
This is a basic test around the async http client of micropython, which is NOT built-in with the official uPy image on download page of offcial site. Anyway it can be easily installed thru the upip – make sure you have sufficient free RAM before the installation though, otherwise it could fail.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
WebREPL connected >>> import gc >>> import upip >>> upip.install("micropython-uaiohttpclient") Installing to: /lib/ Warning: micropython.org SSL certificate is not validated Installing micropython-uaiohttpclient 0.5.1 from https://micropython.org/pi/uaiohttpclient/uaiohttpclient-0.5.1.tar.gz >>>utils.free() '61.11%' >>>gc.collect() >>>utils.free() '93.75%' |
I somehow guess that the reason it’s not included in standard build might be… the asyncio is not quite common among the uPy developers? So people can use the built-in urequests instead.
Well I’m not an async – await Python guy on Mac/Linux either (since we’ve an powerful O/S anyway), but here I consider it might be the only method, AFAIK, to make my ESP32 nodeMCU work with kinda multi-tasking with uPy, non-preemptive, though. If not, then I’m about to be left with no choice and head back to the C stuff (with a traditional RTOS), right?
完整阅读本篇»基于Flask的简易webtelnet和webssh
Chinese version README of the Github repo – flask-remote-terminal.
简而言之，一台具备多用户支持的，仅限使用telnet/ssh，访问远程固定地址的，web终端。
演示截图：
有啥稀罕的
- 只可访问远程地址，非本机终端
- 目前仅限telnet（支持十几年前老设备用）和ssh访问，代码中也可增加其他协议，但始终受控
- 仅限访问固定远端地址（IP/域名），代码config可配，一旦服务运行后不可更改
- 服务端session存储pid和fd等，用于多用户支持
参考项目
- 一个教学工程 pyxterm.js 作者 Chad Smith
需求如此“扭曲”，何解
通过web终端去管理一台特定的中转机，其多数端口是（在特定时间段内）代理到真正需要管理的目标机。具体需求如下：
- 同多数web terminal一样，浏览器即开即用，免安装
- 只允许访问特定地址（中转机），避免被抓肉鸡
- 只允许使用telnet和ssh进行连接，不可自选其他客户端命令，在此基础上允许用户自行输入用户名和端口号
- 只用于远程连接，在用户exit退出终端后，也无法回到shell操作提供该服务的server
京公网安备 11011502004657号