|
|
|
testing the air at Brewster Street
Tuesday, January 7 2025
This morning Gretchen and I drove over to the Brewster Street rental to meet up with Robert, a quirky older man in a leg brace who would be performing an air quality check. Before he got going, he showed us what all he would be doing, which seemed to involve destroying one of his testing pods. He would be attaching pods to three different air suction and blowing devices and then sending the filters from the pods to a lab to have them analyzed. The process involved dissolving away the filter and then fixing any trapped particles in a resin that then needed to cure, and that would be examined microscopically. (I wasn't sure if this would be done by a human or by an automated process.) This all seemed straightforward to me, and neither Gretchen nor I cared to hear about the very different process used to detect mold spores, especially given how cold it was outside. Somehow we kept him from launching into a show and tell about that, and we went to knock on the tenant's door. The female half of the couple was home and let us in. Robert explained what he would be doing and how long it would take (about 90 minutes). He'd be running tests in the living room, the basement, and also outdoors. Once all that was explained, Gretchen signaled to me that she wanted to confront the tenant about calling the Kingston Building Department on us, the thing that had resulted in a violation that we'd learned about on Sunday. When Gretchen asked why she'd filed a complaint, the tenant insisted that she and her partner hadn't and that they had only called the Building Department to find out what to do, and they'd insisted on sending out inspectors who had then filed the violation. The tenant hadn't wanted that to happen, but that's what the result was. This satisfied me as a satisfactory explanation, and I immediately stopped hating the tenant. "That makes sense," I said, which then gave Gretchen (as she told me later) the signal that we could drop the issue and stop holding it against the tenants. As part of the tenant's attempt to defuse the tension around that issue, she now seemed to be okay with us using an appropriate product to paint over any fraying asbestos should the house pass the air quality test that was being conducted.
Our business at Brewster Street was over and the dogs (whom we'd brought with us) needed a walk, so we drove to the large Wiltwyck Cemetery nearby (which we'd never visited in all our time here). We found a place to park on the other side of a knoll, hoping to avoid cemetery employees roaming the grounds in a big truck and a golf cart. When we saw the golf cart approaching, we headed into a patch of woods overlooking the mostly-unpopulated urban gorge which carries Wilbur Avenue down to the Rondout. We thought for sure the employees were going to yell at us about our off-leash dogs when they stopped and got out of the golf cart, but it turned out that all they were doing was picking up fallen branches and carrying them to a refuse pile at the west end of the cemetery grounds. They weren't troubled by what we were doing at all.
Since leaving the Adirondack cabin on Sunday night, I've noticed that occasionally it will lose internet connectivity for fifteen minutes to an hour at a time. So I looked at the configuration I'd last written to the Hotspot Watchdog and found the reason why: a configuration constant called granularity_when_in_connection_failure_mode was set to 60 when it should've been something like five. That's the amount of time in seconds that it should wait after rebooting the Moxee hotspot before attempting another connection to the backend. 60 seconds is way too much time, and apparently it screws up the reset process so badly that it can take an hour for it recover. Fortunately, though, it does eventually recover. When I have that constant set to five, the watchdog usually manages to fix internet outages caused by hotspot confusion in under a minute.
This evening Gretchen made an InstantPot of pressure-cooked red beans in a beer-based-broth which she intended us to eat with coconut brown rice she'd made earlier in the day. But the beans, which were (unusually for us) made from a bag of dried beans, took longer to cook than expected. So we ended up eating the rice with navy beans from a can. With a little hot sauce, it was plenty good enough.
Earlier today I'd had enough dread about confronting the tenant at Brewster Street about them reporting us to the Kingston Building Department that I'd taken a 150 mg of pseudoephedrine. This evening after watching Jeopardy! and It's Florida, Man, I directed the resulting mental focus on the task of building out some more features on my ESP8266 Remote Control System. I'd figured out a better way to handle the four reservedX columns on the device_log table, the table where all weather data is now logged. These columns are there to accept data from esoteric sensors (or perhaps additional common sensors, such as those that sense temperature). I'd already thought of a way to represent the different data that they store on a device-by-device basis by having a way to relabel them using columns from the device table. But today I realized I needed more metadata about those relationships, particularly if I wanted to store a transform function to convert raw sensor data in those columns into units that make more sense to the user. (For example, I might be getting "millimeters from time-of-flight sensor" when what I want to see is "inches of snow.") It might also be useful to distinguish between data that had already been converted by such an transform from data that was stored raw and needed to be transformed before being presented to the user. So I created a new table called device_column map with the following columns: device_column_map_id, device_id, table_name, column_name, display_name, process_algorithm, process_before_save (a boolean), created, and tenant_id. This will allow me to essentially rename any column in the database related to a particular device.
For linking purposes this article's URL is:
http://asecular.com/blog.php?250107 feedback
previous | next |
