-
Enclosures
02/19/2019 at 12:02 • 0 commentsI'm not really happy with what I've done for enclosures so far, and the more iterations I do the smaller I'm getting things so I've been thinking about getting a small run of PCBs done, which in turn makes me think more seriously about finding an enclosure to actually size the PCB to. So I picked up a set of Hammond 1551V enclosures from Arrow (I couldn't find any on Amazon).
9V for size comparison - I have a hard time with picking items from photos that have no reference (as seen on almost every catalog and most stores). Clockwise starting at the battery these are sizes 2, 4, 1 and 3.
The ESP 8266 just fits on the size 1 (40x40mm) enclosure base - I wonder if I can get a BME280 in with it - but even if I did Im sure self heating would spoil the measurements. The current interation of Ori just fits on the size 2 (40x80mm) base. I think with a custom PCB it would be comfortable and have enough room to put an insulating barrier to have the sensor breakout isolated from the heat generated by the microcontroller. I do think it would take a bit more work but may be possible to shoehorn Dwalin v3 into the size 4 (80x80mm) enclosure. The buck regular module I'm using will be a problem I think.
-
Enclosures
02/19/2019 at 11:56 • 0 commentsI'm not really happy with what I've done for enclosures so far, and the more iterations I do the smaller I'm getting things so I've been thinking about getting a small run of PCBs done, which in turn makes me think more seriously about finding and enclosure to actually size the PCB to. So I picked up a set of Hammond 1551V enclosures from Arrow (I couldn't find any on Amazon).
9V for size check comparison - I have a hard time with picking items from photos that have no reference.
The ESP 8266 just fits on the size 1 (40x40mm) enclosure base - I wonder if I can get a BME280 in with it - but even if I did Im sure self heating would spoil the measurements. Ori just fits on the size 2 (40x80mm) base. I think with a custom PCB it would be comfortable and have enough room to put an insulating barrier to have the sensor breakout isolated from the heat generated by the microcontroller. I do think it would take a bit more work but may be possible to shoehorn Dwalin v3 into the size 4 (80x80mm) enclosure.
-
Yak Shaving - aka infrastructure work - aka Erebor
02/15/2019 at 12:14 • 0 commentsIn order to get OTA updates to work for Dwalin v2 (ESP32 based) and Ori (ESP8266) in a secure manner, an https server needs to be available somewhere. In order to reduce dependencies on network infrastructure, I want this to be a server in the house. For development so far I've been running a copy of "Ubuntu under Windows" from the Microsoft store on my development/gaming machine. Unfortunately this isn't really the same as a VM of Ubuntu - it's more of "part of the userspace but not the kernel and so not quite all of what you are used to" situation. I've been using a mix of Cygwin, MSYS32 and Microsoft's Ubuntu on the Windows machine for a while and none of them are really like just using an Ubuntu machine so I decided this is the time just get a dedicated machine.
So I picked up a refurbished HP Elite 8300 SFF off Amazon (I'm guessing these are from 'off lease returns' from businesses) and built that with a full install of Ubuntu 18.10. Named machine erebor.
Arduino IDE installed on erebor
XPRA on that gives me a nice desktop using RDP from my Windows machine.
I want to use a Let's Encrypt certificate (rather than just a self-signed one) for securing the OTA - however because I'm at home behind Comcast NAT, I can't use the http-01 authentication mechanism - I'll need to use dns-01. That in turn means I needed to move my nameserver from my registrar (namecheap) over to one that plays nicely with available tools to script updates to TXT records (Hurricane Electric).
I want to be able to reach Erebor from the outside in some way, so I set up an OpenVPN tunnel to each of the two cloud VMs (one on AWS and one on Azure) that I have - so I can reach those from outside and SSH over the OpenVPN tunnel back to Erebor. This is essentially the same mode that things like 'LogMeIn' work but managed by me, not by a company that will decide to eliminate features ona whim (yes, I'm still sore that LogMeIn removed a functional-for-my-purposes HTML5 mode from my paid account with them).
Work yet to do:
- Complete Let'sEncrypt configuration on erebor
- Configure Mosquitto on erebor
- Configure MQTT on Dwalin v2 and Ori
- Complete configuration of OTA on Ori
- Rework configuration of OTA on Dwalin v2 (it was functional pointed at the 'Ubuntu under Windows' setup)
- Setup development environment for ESP-IDF targetting ESP32 for Dwalin v2 on erebor
- Link ESP-IDF and Arduino storage to git
- Setup apache on erebor to properly handle OTA requests from both types of OTA (ESP-IDF does it differently from how Arduino OTA does) - OR recode Dwalin v2 to be able to use OTA the same way so I only need one type of setup in apache on erebor.
Then I will be done with the yak shaving (is one ever really done?) and can get back to setting up firmware on Dwalin and Ori.
-
Ori - back on track
02/11/2019 at 03:31 • 0 commentsWhat you are seeing here is the Raspberry Pi Zero W that was part of Dwalin v1 repurposed to fix my damage to Ori.
The right angle header at the top of the Ori board is new - bringing out 3.3v, gnd, TX, RX. Not actually using 3.3v here (skipped pin). Gnd, TX and RX are connected to Pi GPIO header to appear under Linux on Dwalin as /dev/ttyS0
Built a new copy of the sketch to confirm I'm able to flash this way, copied from Windows machine to Dwalin via SSH over WiFi. From Dwalin using esptool.py to write to the flash on the ESP8266. Showing on the OLED is a visual simplification to confirm successfully flashing. BME280 not presently plugged in so getting error values instead of real readings.
sudo esptool/esptool.py --chip esp8266 --port /dev/ttyS0 write_flash 0x00000 tempnode-v0.1.ino.bin
From here I should be able to get OTA firmware updates to work.
-
Ori - annoying mistake
02/10/2019 at 17:40 • 0 commentsI've made some mistakes here and there in this project, but generally they have been either learning opportunities or correctable.
Latest mistake was not removing the circuit board from enclosure for Ori when drilling out the side to make an entrance for the USB cable. The drill bit grabbed onto the plastic and pulled - crashing right into the microUSB connector on the ESP8266 module. The problem is that in order to reduce the Z axis size of the assembly, I soldered the ESP8266 to headers soldered to the protoboard - no connector. This means removing the ESP8266 with just solder sucker and solder wick is almost certain to destroy it. The issue isn't so much the cost of the ESP8266, it's that rework is likely to ruin everything I've done on Ori to date - it seems like it's likely simpler and faster to just start over on Ori rather than try to fix this.
I wired up to Vin & Ground and I am able to power Ori and it runs the existing script without a problem - the issue is how to get any changed firmware into place. If I had already loaded the OTA firmware update code, this wouldn't be a problem.
Lessons for the day:
- Rushing produces bad results
- Load OTA firmware updates into the module first - before even soldering headers on
-
Ori - office temperature sampling node
02/07/2019 at 04:15 • 0 commentsOri, wired and functional at a very basic level.
This is a ESP8266 board with a small 128x32 OLED and two buttons for input and a BME280. I still need to change header for BME280 to a right angle to cut down overall height. Quite a lot smaller than Dwalin v2; I'm wondering if perhaps I could drive Dwalin v3 with one of these and fit it in a much smaller enclosure.
Functional in this code:
- Button input
- Sensor readings from BME280
- OLED display of sensor reading
Two major items to code up: OTA firmware updates and pushing sensor readings over the network to MQTT and prometheus
-
Dwalin enclosure work
02/04/2019 at 11:55 • 0 commentsI've been working on cobbling together the enclosure for Dwalin. It's not nearly as clean and tidy as I'd like.
Showing here, I've got the clear cover taped off for the portion of the OLED that will show through once I spray paint the case glossy white. While masking this out I discovered that I seem to have a 128x96 OLED panel as opposed to the 128x128 that I ordered and is silk-screened on the back of the PCB. When in native rotation, it's 128 wide, 96 tall. When in the rotation I need it's 96 wide and 128 tall, however my x coordinate in u8g2 starts at 32 (if I start at 0, it draws off the left edge of the display). The reason I think it's really 128x96 is that in the 96 pixel dimension it is centered within the glass. If it was damage, I would expect it out be off center.
Marking out the inside for where I'm drilling holes for phototransistor and NeoPixel
Not shown are hole in the back for routing 3 conductors for furnace interface and incoming power and one on the side so my BME280 gets to sample ambient air outside the enclosure not just the air within.
Haven't done much firmware work other than coding around my 128x96 limitation.
-
Dwalin (main thermostat) now self-OTA updates
01/28/2019 at 12:04 • 0 commentsCoding coding... I've got Dwalin now able to update itself over-the-air. To get to this point, I needed to have two different inputs from the rotary encoder switch, so I changed from triggering action on the down press to triggering on the release, and distinguishing 'short' from 'long' button press.
At this point, I've got the following pages of display info:
- Info (primarily timing info on drawing the display since I was working on OLED i2c refresh speed)
- Temperature (this is the default that it will go back to if no input for 20s)
- WiFi status
- Bluetooth status (blank at the moment)
- Nightlight (both light sensor and NeoPixel status)
- Firmware
On the Firmware page, a long press initiates OTA update.
For my own reference in the future, here is the memory usage as reported by ESP IDF at this point:
Total sizes: DRAM .data size: 11648 bytes DRAM .bss size: 27648 bytes Used static DRAM: 39296 bytes ( 141440 available, 21.7% used) Used static IRAM: 75372 bytes ( 55700 available, 57.5% used) Flash code: 602426 bytes Flash rodata: 154216 bytes Total image size:~ 843662 bytes (.bin may be padded larger)
I have a lingering issue that I need to dig into, which is that turning the rotary encoder encoder at a pace that's anything faster than 'pretty slow' simply drops all events.
I think this has to do with the interplay between way I'm debouncing and with the fact that I'm leaving a delay at the end of the main loop of 10ms. I wonder if I should scale the delay based on if I'm in 'idle' or not (long delay in idle, short delay out of idle). Perhaps combine that with an interrupt on any event from the rotary encoder - so take it out of idle on the first interrupt, then leave that interrupt disabled until going back into idle.
-
Dwalin (main thermostat) wiring fixed
01/26/2019 at 04:10 • 0 commentsFound a missed solder bridge on ground pin of NeoPixel strip. With that in place, I've got simple nightlight functionality working. I am seeing 'flicker of NeoPixel during WiFi activity' that I've seen mention of elsewhere - I may need to move Vcc for the NeoPixel from the ESP32 3.3v bus to 5v bus off the buck regulator.
-
Dwalin (main thermostat) wiring completed
01/22/2019 at 03:12 • 0 commentsOf course, saying the wiring is complete just invites the discovery of wiring problems, that said, I believe all hardware is wired up. No enclosure yet - the one I was planning on working with turns out to be about 3mm short on the Z axis. I keep finding pins on the ESP32 that are "yes, it's open but you can't use that pin".
On the bench: