diff --git a/assets/css/extended/custom.css b/assets/css/extended/custom.css index 4fe3fe5..c7c0eff 100644 --- a/assets/css/extended/custom.css +++ b/assets/css/extended/custom.css @@ -38,6 +38,16 @@ body { margin: 1rem auto; } +/* + The set caption is a flex item like the figures beside it, so without a full-width basis it + packs onto the end of the last row and reads as a caption for whichever image it lands next + to. Full width puts it on its own row under the set, which is what it describes. +*/ +.gallery > figcaption { + flex: 0 0 100%; + text-align: center; +} + .gallery-cols-1 figure { width: 100%; } diff --git a/checks/README.md b/checks/README.md index 435916f..83bc682 100644 --- a/checks/README.md +++ b/checks/README.md @@ -84,6 +84,24 @@ A count is all the check can observe, and two causes reach each direction: it ri **Both directions read absolute references as well as relative ones.** Hugo writes an absolute URL wherever a template resolves one against the base, which the entry-cover image on every list page does. Reading only rooted paths made those files look linked from nowhere while they were being displayed, and left a broken one unchecked in the other direction. The origin is read from the home page's canonical link rather than assumed, since staging and production build with different base URLs and a hardcoded host would check one environment's output against another's. No canonical link is a hard failure, because a guessed origin inflates the orphan count by exactly the pages that use one. +## The gallery check, which no direction above can reach + +Every check above reasons about a URL: whether it renders, whether it resolves, whether anything points at it. Content misplaced **inside** a gallery satisfies all of that. The file exists, the reference resolves, and something links it, so the media surface is green in both directions while the page is laid out wrong. The defect is one of structure, which is why three variants of it survived the conversion and every gate since. + +A gallery is a flex row whose column widths come from `.gallery-cols-N figure`. Anything in there that is not a `figure` gets no width from that rule and is rendered as one more item in the row. So the check reads the built pages and fails on any direct child of a gallery container that is not a `figure` or the gallery's own `figcaption`. + +The three shapes it found, all of them conversion artifacts, and each verified against the captured live site before being changed: + +| Shape in the markdown | What the old platform had | +| --- | --- | +| Caption text appended after the last `figure` shortcode's `}}` | `
`, a caption for the **set** | +| A bare `![](…)` image | `
  • ` | +| A linked `[![](…)](…)` image | the same, with an `` **inside** the figure | + +**The first shape is why the capture is consulted rather than the markup.** A reviewer reading only the source reasonably suggests moving the text into the last figure's `caption` parameter, which is what a per-image caption would need. The capture shows all eleven were gallery-level captions, so that fix would have attributed a caption for a set of four images to whichever one happened to be last, and it would have looked correct. + +The gallery shortcode therefore takes a `caption` of its own and renders the container as a `figure`, since `figcaption` is only valid as a figure's child. The theme already styles `figure > figcaption`, so a set caption needs no rule beyond a full-width flex basis to keep it off the end of the last row. + ## What the orphans are The count is not a backlog. It opened at 120 and was adjudicated against the captured live site under `blog-capture/mirror/`, which holds a crawl of the old platform including all 328 URLs the contract requires: diff --git a/checks/check-url-parity.py b/checks/check-url-parity.py index c2d4493..2d017fa 100755 --- a/checks/check-url-parity.py +++ b/checks/check-url-parity.py @@ -10,6 +10,7 @@ import pathlib import re import sys +from html.parser import HTMLParser from urllib.parse import unquote # A truncated list would make every assertion below it pass vacuously while the gate stays green. @@ -37,6 +38,12 @@ # slack can never accumulate for a later regression to hide in. ORPHANED_MEDIA = 98 +# Every check above returns a list, and the shared summary called all of them "missing". That is +# what a URL that did not build is, and it is not what a stray node inside a gallery is: those are +# present, which is the whole complaint. The default stays "missing" so a check added later reads +# the way the older ones do unless it says otherwise. +FAILURE_NOUN = {"gallery": "stray nodes"} + def load(name): lines = [ln.strip() for ln in (CHECKS / name).read_text().splitlines()] @@ -189,6 +196,102 @@ def check_orphans(public, refs): return orphaned +class GalleryScan(HTMLParser): + """Collect anything inside a gallery container that is not one of its permitted children. + + A gallery is a flex row of figures, so its column widths are set by `.gallery-cols-N figure`. + Anything else landing in there is not laid out by that rule and is rendered as one more item + in the row. + + This reads the built HTML, so it sees fewer shapes than the markdown has, and deliberately: + three source patterns reached it, a set caption written as text trailing a figure shortcode, + a bare markdown image, and a linked one, and they arrive here as a bare text node, a `

    ` + wrapping images, and an `` with a `
    ` beside it. Enumerating source patterns would + make this a list to extend every time the conversion surprises us again. Naming the one + invariant instead, that a gallery holds figures and its own caption, covers the shape nobody + has thought of yet, which is how the third of the three was found after the first two. + """ + + # A void element never closes, so counting it as an open tag desynchronizes the depth for the + # rest of the document and every later gallery reads as containing whatever follows it. + VOID = {"area", "base", "br", "col", "embed", "hr", "img", "input", + "link", "meta", "param", "source", "track", "wbr"} + ALLOWED = {"figure", "figcaption"} + + # There is deliberately no handle_startendtag override. HTMLParser's own implementation + # forwards a self-closing tag to handle_starttag and then handle_endtag, so `
    `, `
    ` + # and `` are already reported and already leave the depth balanced. Adding an override + # to "support" them is what would break it, by counting a pair the base class already splits. + # Verified on those three spellings and on a self-closing non-void `

    `. + + def __init__(self): + super().__init__(convert_charrefs=True) + self.findings = [] + self.saw_gallery = False + # None outside a gallery; otherwise the number of elements open within the current one, + # so zero means the parser is looking at a direct child. + self.depth = None + + def handle_starttag(self, tag, attrs): + classes = dict(attrs).get("class", "").split() + if self.depth is None: + if tag == "figure" and "gallery" in classes: + self.depth = 0 + self.saw_gallery = True + return + if self.depth == 0 and tag not in self.ALLOWED: + self.findings.append(f"<{tag}> as a direct child") + if tag not in self.VOID: + self.depth += 1 + + def handle_endtag(self, tag): + if self.depth is None or tag in self.VOID: + return + if self.depth == 0: + # The gallery's own closing tag. + self.depth = None + else: + self.depth -= 1 + + def handle_data(self, data): + # Whitespace between elements is just the template's formatting. + if self.depth == 0 and data.strip(): + self.findings.append(f"bare text {data.strip()[:60]!r}") + + +def check_galleries(public): + """Check that every gallery holds only figures and its own caption. + + Neither the assets nor the orphans check can see this: both ask whether a reference resolves + or is reached, and content misplaced inside a gallery resolves and is reached exactly as it + would anywhere else. The defect is purely one of structure, so nothing that reasons about + URLs can observe it, which is why it survived the conversion and every gate since. + """ + findings, pages = [], 0 + for path in sorted(public.rglob("index.html")): + html = path.read_text(encoding="utf-8", errors="replace") + # Cheap reject first, since parsing every built page costs far more than one substring + # test and galleries appear on a handful of them. The test is the bare word rather than + # `class="gallery`, because minification drops the quotes around a value that does not + # need them and says nothing about class order, so the quoted form skips a page whose + # markup is merely spelled differently and the gate passes vacuously. This form cannot: + # the parser below requires the class token `gallery`, so a page it would find always + # contains this string. Matching a page that only mentions the word costs one parse. + if "gallery" not in html: + continue + scan = GalleryScan() + scan.feed(html) + # Counted from what the parser actually found rather than from the reject above, so the + # reported number stays "pages carrying a gallery" and not "pages the word appears on". + if not scan.saw_gallery: + continue + pages += 1 + rel = str(path.relative_to(public)).replace("\\", "/") + findings += [f"{rel}: {finding}" for finding in scan.findings] + print(f"gallery: {pages} pages with galleries, {len(findings)} stray nodes inside one") + return findings + + def main(argv): if len(argv) != 2: sys.exit(f"usage: {argv[0]} ") @@ -198,26 +301,27 @@ def main(argv): refs = collect_refs(public) failures = [] - for label, missing in ( + for label, found in ( ("render", check_render(public)), ("media", check_media(public)), ("assets", check_assets(public, refs)), ("orphans", check_orphans(public, refs)), + ("gallery", check_galleries(public)), ): - if missing: - failures.append((label, missing)) + if found: + failures.append((label, found)) if not failures: print("\nPASS - the built site honors the URL contract") return 0 print() - for label, missing in failures: - print(f"FAIL {label}: {len(missing)} missing") - for item in missing[:20]: + for label, found in failures: + print(f"FAIL {label}: {len(found)} {FAILURE_NOUN.get(label, 'missing')}") + for item in found[:20]: print(f" {item}") - if len(missing) > 20: - print(f" ... and {len(missing) - 20} more") + if len(found) > 20: + print(f" ... and {len(found) - 20} more") return 1 diff --git a/content/posts/2020/02/02/recovering-the-firmware-on-a-supermicro-bpn-sas3-846el1-backplane.md b/content/posts/2020/02/02/recovering-the-firmware-on-a-supermicro-bpn-sas3-846el1-backplane.md index 625954c..d333873 100644 --- a/content/posts/2020/02/02/recovering-the-firmware-on-a-supermicro-bpn-sas3-846el1-backplane.md +++ b/content/posts/2020/02/02/recovering-the-firmware-on-a-supermicro-bpn-sas3-846el1-backplane.md @@ -37,8 +37,8 @@ I removed the motherboard from the old chassis and installed it in the new SC846 {{< figure src="/media/2020/01/img%5F5897.jpg?w=1024" alt="" caption="" >}} {{< figure src="/media/2020/01/img%5F5898.jpg?w=1024" alt="" caption="" >}} {{< figure src="/media/2020/01/img%5F5899.jpg?w=768" alt="" caption="" >}} -![](/media/2020/02/img_5973.jpg?w=1024) -![](/media/2020/02/img_5980.jpg?w=768) +{{< figure src="/media/2020/02/img_5973.jpg?w=1024" alt="" caption="" >}} +{{< figure src="/media/2020/02/img_5980.jpg?w=768" alt="" caption="" >}} {{< /gallery >}} I powered the machine up through remote IPMI KVM, all looked good, and I booted into my Ubuntu Server USB stick so I could SSH into the box, and update the firmware. diff --git a/content/posts/2020/06/21/moving-from-unraid-to-proxmox-ve.md b/content/posts/2020/06/21/moving-from-unraid-to-proxmox-ve.md index 1c9ee23..dae8410 100644 --- a/content/posts/2020/06/21/moving-from-unraid-to-proxmox-ve.md +++ b/content/posts/2020/06/21/moving-from-unraid-to-proxmox-ve.md @@ -610,12 +610,12 @@ Here are a few screenshot of the end result: {{< gallery cols="3" >}} -[![](/media/2020/06/2020-06-21-1.png?w=1024)](/media/2020/06/2020-06-21-1.png?w=1024) -[![](/media/2020/06/2020-06-21-2.png?w=1024)](/media/2020/06/2020-06-21-2.png?w=1024) -[![](/media/2020/06/2020-06-21-3.png?w=1024)](/media/2020/06/2020-06-21-3.png?w=1024) -[![](/media/2020/06/2020-06-21-4.png?w=1024)](/media/2020/06/2020-06-21-4.png?w=1024) -[![](/media/2020/06/2020-06-21-9.png?w=1024)](/media/2020/06/2020-06-21-9.png?w=1024) -[![](/media/2020/06/2020-06-21-6.png?w=1024)](/media/2020/06/2020-06-21-6.png?w=1024) -[![](/media/2020/06/2020-06-21-7.png?w=1024)](/media/2020/06/2020-06-21-7.png?w=1024) -[![](/media/2020/06/2020-06-21-8.png?w=1024)](/media/2020/06/2020-06-21-8.png?w=1024) +{{< figure src="/media/2020/06/2020-06-21-1.png?w=1024" alt="" link="/media/2020/06/2020-06-21-1.png?w=1024" caption="" >}} +{{< figure src="/media/2020/06/2020-06-21-2.png?w=1024" alt="" link="/media/2020/06/2020-06-21-2.png?w=1024" caption="" >}} +{{< figure src="/media/2020/06/2020-06-21-3.png?w=1024" alt="" link="/media/2020/06/2020-06-21-3.png?w=1024" caption="" >}} +{{< figure src="/media/2020/06/2020-06-21-4.png?w=1024" alt="" link="/media/2020/06/2020-06-21-4.png?w=1024" caption="" >}} +{{< figure src="/media/2020/06/2020-06-21-9.png?w=1024" alt="" link="/media/2020/06/2020-06-21-9.png?w=1024" caption="" >}} +{{< figure src="/media/2020/06/2020-06-21-6.png?w=1024" alt="" link="/media/2020/06/2020-06-21-6.png?w=1024" caption="" >}} +{{< figure src="/media/2020/06/2020-06-21-7.png?w=1024" alt="" link="/media/2020/06/2020-06-21-7.png?w=1024" caption="" >}} +{{< figure src="/media/2020/06/2020-06-21-8.png?w=1024" alt="" link="/media/2020/06/2020-06-21-8.png?w=1024" caption="" >}} {{< /gallery >}} diff --git a/content/posts/2022/10/30/installing-flair-smart-vents-to-keep-room-temperatures-balanced.md b/content/posts/2022/10/30/installing-flair-smart-vents-to-keep-room-temperatures-balanced.md index 93d29bd..af3b68d 100644 --- a/content/posts/2022/10/30/installing-flair-smart-vents-to-keep-room-temperatures-balanced.md +++ b/content/posts/2022/10/30/installing-flair-smart-vents-to-keep-room-temperatures-balanced.md @@ -56,14 +56,14 @@ To get started, I ordered a [puck](https://flair.co/products/puck) and a couple The look and feel of the Puck was a bit disappointing for the price, small non-touch monochrome display, and uneven feeling push to actuate action. The [Flair Puck](https://amzn.to/3rOr6gS) is about $119 while an [Ecobee3 Lite](https://amzn.to/3TfSNLo) is about $149, and the Ecobee has a nice big color touch screen. Granted, the puck is about half the size of the Ecobee so more discreet, and I'm not planning on using the puck for anything other than an internet gateway, so look and feel was not that important to me. -{{< gallery cols="4" >}} +{{< gallery cols="4" caption="FLAIR puck vs. my old Ecobee3" >}} {{< figure src="/media/2022/10/img_1646.jpg?w=1024" alt="" caption="" >}} {{< figure src="/media/2022/10/img_1647.jpg?w=594" alt="" caption="" >}} {{< figure src="/media/2022/10/img_1655.jpg?w=665" alt="" caption="" >}} -{{< figure src="/media/2022/10/img_1657.jpg?w=426" alt="" caption="" >}}FLAIR puck vs. my old Ecobee3 +{{< figure src="/media/2022/10/img_1657.jpg?w=426" alt="" caption="" >}} {{< /gallery >}} I installed the iOS app, set the puck in gateway only mode, followed the installation steps in the app, including creating an account, connecting the puck to WiFi, and connecting Flair to Ecobee for access to my thermostats. I installed batteries in a vent, without installing the actual vent but observing its behavior, and added the vent to Flair using the iOS app by entering pairing mode, no problems. @@ -71,10 +71,10 @@ I installed the iOS app, set the puck in gateway only mode, followed the install When I completed the required setup steps I logged into the web portal on my PC to explore, and I was confused to see that the system appeared to be in heating mode. I verified that Ecobee was still in cooling mode, and I changed the Flair mode from Heat to Manual. -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="Ecobee in cool mode while FLAIR reports heat mode" >}} {{< figure src="/media/2022/10/2022-10-06-1.png?w=1024" alt="" caption="" >}} -{{< figure src="/media/2022/10/2022-10-06.png?w=1024" alt="" caption="" >}}Ecobee in cool mode while FLAIR reports heat mode +{{< figure src="/media/2022/10/2022-10-06.png?w=1024" alt="" caption="" >}} {{< /gallery >}} I created a post in the Flair [community forum](https://support.flair.co/hc/en-us/community/topics/115000084371-Flair-Discussion) asking for help, next day a support ticket was logged for me by a moderator, and it took another four days for support to respond. A five day turnaround for support is not very responsive. @@ -92,33 +92,33 @@ The Flair vents are longer but narrower than my current vents, and that was a bi I ended up removing the old vents, and visited my paint store several times to color match various wall or ceiling colors, I sanded, caulked, and patched drywall spaces around ducts. It took several weekends of my time, I am not a great at drywalling or painting, the result is not very pretty, but the vents are up. -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="FLAIR vent construction" >}} {{< figure src="/media/2022/10/img%5F1642.jpg?w=604" alt="" caption="" >}} {{< figure src="/media/2022/10/img%5F1643.jpg?w=603" alt="" caption="" >}} -{{< figure src="/media/2022/10/img%5F1644.jpg?w=943" alt="" caption="" >}}FLAIR vent construction +{{< figure src="/media/2022/10/img%5F1644.jpg?w=943" alt="" caption="" >}} {{< /gallery >}} -{{< gallery cols="5" >}} +{{< gallery cols="5" caption="FLAIR vent is smaller than standard vents" >}} {{< figure src="/media/2022/10/img_1651.jpg?w=663" alt="" caption="" >}} {{< figure src="/media/2022/10/img_1663-edited.jpg" alt="" caption="" >}} {{< figure src="/media/2022/10/img_1665-edited-1.jpg" alt="" caption="" >}} -{{< figure src="/media/2022/10/img_1668.jpg?w=589" alt="" caption="" >}}FLAIR vent is smaller than standard vents +{{< figure src="/media/2022/10/img_1668.jpg?w=589" alt="" caption="" >}} {{< /gallery >}} With all the trouble caused by the too narrow vents, I wondered if there was a standard to sizes, and if so, if Flair was following it. I researched vent sizes across several HVAC supply sites and hardware stores, and my conclusion is that the Flair [vents](https://www.flair.co/smart-vent-engineering-and-dimensional-data-public) are always longer and narrower than standard wall/ceiling vent sizes (I did not compare floor vent sizes). -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="FLAIR vent sizes vs. standard vents sizes" >}} {{< figure src="/media/2022/10/screenshot-2022-10-13-210638.png?w=1024" alt="" caption="" >}} {{< figure src="/media/2022/10/screenshot-2022-10-13-210202.png?w=949" alt="" caption="" >}} -{{< figure src="/media/2022/10/screenshot-2022-10-13-210127.png?w=751" alt="" caption="" >}}FLAIR vent sizes vs. standard vents sizes +{{< figure src="/media/2022/10/screenshot-2022-10-13-210127.png?w=751" alt="" caption="" >}} {{< /gallery >}} In my opinion making the vents smaller than common sizes is a major design flaw, and I do wonder if Flair designers and engineers ever actually field tested the vents on real ceilings or walls, or if they only focused on drop in replacement floor vents? So unless you are are doing new construction, or have perfect paint and drywall, get ready for patching and painting. @@ -130,10 +130,10 @@ After a few days of having a few vents installed, I noticed that when closed som https://videopress.com/v/mjkR6GnH?resizeToParent=true&cover=true&preloadContent=metadata&useAverageColor=true Whistling vent -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="Caulking gaps between vent and air duct" >}} {{< figure src="/media/2022/10/img%5F1675.jpg?w=545" alt="" caption="" >}} -{{< figure src="/media/2022/10/img%5F1684.jpg?w=768" alt="" caption="" >}}Caulking gaps between vent and air duct +{{< figure src="/media/2022/10/img%5F1684.jpg?w=768" alt="" caption="" >}} {{< /gallery >}} A day or so later I heard a familiar whistling noise again, and I found a vent that I did caulk and seal was now also whistling when closed. I removed the vent, double checked that it was properly caulked and sealed, it was. Thus this noise must be coming either from air blowing between the vent flange and the drywall, or from the screw slots on the long sides of the vent flange, or from the mechanical vent veins themselves. I can't do anything about noisy vent veins, but I can try to seal the flange. I applied some soft thin foam weatherstripping around the edge of the vent flange, creating a tight seal between the vent flange and the drywall, and also covering the unused and open flange screw holes. @@ -141,10 +141,10 @@ A day or so later I heard a familiar whistling noise again, and I found a vent t My initial attempt at using 3/8" thick foam from my local hardware store was unsuccessful, the foam compresses very well, but not enough to sit flush with the wall. I tried again using 1/4" thick [foam](https://amzn.to/3Sw5f8U), and that compressed well enough to seal the unused screw holes and sit flush with the drywall. -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="Foam tape sealing around flange" >}} {{< figure src="/media/2022/10/img%5F1766.jpg?w=768" alt="" caption="" >}} -{{< figure src="/media/2022/10/img%5F1765.jpg?w=768" alt="" caption="" >}}Foam tape sealing around flange +{{< figure src="/media/2022/10/img%5F1765.jpg?w=768" alt="" caption="" >}} {{< /gallery >}} #### Flanges @@ -154,25 +154,25 @@ As I was patching and painting, I wondered if there wasn't an easier way to obsc I used [Fusion 360](https://www.autodesk.com/products/fusion-360/) to create a prototype flange for a 12x6 vent that could be laser cut from thin rigid plastic. -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="Fusion360 flange design" >}} {{< figure src="/media/2022/10/6x12-v5-1-1.png?w=854" alt="" caption="" >}} {{< figure src="/media/2022/10/6x12-v5-2.png?w=1024" alt="" caption="" >}} -{{< figure src="/media/2022/10/2022-10-25-1.png?w=1024" alt="" caption="" >}}Fusion360 flange design +{{< figure src="/media/2022/10/2022-10-25-1.png?w=1024" alt="" caption="" >}} {{< /gallery >}} I looked for vendors with reasonable pricing and thin white paintable plastic material, [Xometry](https://www.xometry.com/) was too expensive, [SendCutSend](https://sendcutsend.com/) did not offer anything thinner than 3mm, so I used [Ponoko](https://www.ponoko.com/) to cut a 1.5mm thick White Acrylic flange. The 0.8mm White Delrin will be thinner but is more than double the price of 1.5mm White Acrylic. I received the piece in a bout a week, and as designed it is just a tad larger than the original vent to help cover edge damage. As I already did it the hard way by patching and painting, I did not use the flange in my own installation, but I did test fit it and it would have worked fine. -{{< gallery cols="4" >}} +{{< gallery cols="4" caption="Laser cut white acrylic flange" >}} {{< figure src="/media/2022/10/img_1708.jpg?w=726" alt="" caption="" >}} {{< figure src="/media/2022/10/img_1709.jpg?w=617" alt="" caption="" >}} {{< figure src="/media/2022/10/img_1752.jpg?w=601" alt="" caption="" >}} -{{< figure src="/media/2022/10/img_1751.jpg?w=519" alt="" caption="" >}}Laser cut white acrylic flange +{{< figure src="/media/2022/10/img_1751.jpg?w=519" alt="" caption="" >}} {{< /gallery >}} I shared the Fusion 360 projects and DXF files in [Autodesk Gallery](https://gallery.autodesk.com/projects/173188/flair-vent-flanges), and I created a shared [Ponoko cart](https://www.ponoko.com/share/MgBrJSraTWp83F79ob_Ql) with a ready to order 6x10 and 6x12 flange. For sizes other than 6x10 or 6x12 you will need to use Fusion 360 (free for hobby use) and adjust the dimensions in the sketch (\[modify\], \[change parameters\]), then export the projection as a DXF file. @@ -213,12 +213,12 @@ As winter approached it was getting colder at night, and one morning it was too Later the day I wondered how Flair will treat the different modes, and after I logged in I observed that the UI was confused, switching from red and heating mode one moment to blue and cooling mode the next. I verified that Ecobee was correct, heating downstairs and cooling upstairs, so something weird with Flair. In looking at the Flair UI one can see that there is only one operating mode reported, while each of the Ecobee thermostats can individually control heat/cool/auto/off modes. -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="FLAIR is confused between heating and cooling" >}} {{< figure src="/media/2022/10/screen-shot-2022-10-24-at-11.42.47-am.png?w=1024" alt="" caption="" >}} {{< figure src="/media/2022/10/screen-shot-2022-10-24-at-10.26.47-am.png?w=1024" alt="" caption="" >}} -{{< figure src="/media/2022/10/screen-shot-2022-10-24-at-10.25.46-am.png?w=1024" alt="" caption="" >}}FLAIR is confused between heating and cooling +{{< figure src="/media/2022/10/screen-shot-2022-10-24-at-10.25.46-am.png?w=1024" alt="" caption="" >}} {{< /gallery >}} I posted my concern on the Flair [forum](https://support.flair.co/hc/en-us/community/posts/10111024260877-Flair-is-confused-when-one-system-is-on-heat-and-the-other-is-on-cool), and support responded that I have to create multiple logical homes if I want to run the units in different modes. This does not make sense, imagine I have multiple mini-split units, do I need to create a home for each mini-split? I contacted support directly, and they confirmed that all HVAC units must be set to the same mode. If this is a requirement, and the UI gets confused when not correctly set, I'd expect Flair to at least give a warning of an unsupported configuration. @@ -226,10 +226,10 @@ I posted my concern on the Flair [forum](https://support.flair.co/hc/en-us/commu With both Ecobee thermostats set back to Auto, I change the mode from within the Flair UI to Heat, expecting both Ecobees to switch to Heat mode. Instead the Ecobees switched to Heat and a Hold at 75°F, where 75°F seems to have been the current measured temperature. I had to manually remove the hold from both Ecobees to resume normal scheduled operation. This was again confusing and unexpected behavior. -{{< gallery cols="1" >}} +{{< gallery cols="1" caption="FLAIR changed the Ecobee mode to Heat and Hold" >}} {{< figure src="/media/2022/10/screenshot-2022-10-27-184203.png?w=1024" alt="" caption="" >}} -{{< figure src="/media/2022/10/screenshot-2022-10-27-184003.png?w=1024" alt="" caption="" >}}FLAIR changed the Ecobee mode to Heat and Hold +{{< figure src="/media/2022/10/screenshot-2022-10-27-184003.png?w=1024" alt="" caption="" >}} {{< /gallery >}} I have not yet tested Flair as setpoint controller, but for now I'll refrain from making any temperature changes from within the Flair app, and stick to using the Ecobee app. diff --git a/layouts/shortcodes/gallery.html b/layouts/shortcodes/gallery.html index 69be59a..155c409 100644 --- a/layouts/shortcodes/gallery.html +++ b/layouts/shortcodes/gallery.html @@ -1,5 +1,20 @@ +{{/* + A gallery of figures, optionally captioned as a set. + The container is a
    rather than a
    because
    is only valid as a + figure's child, and the caption describes the whole set rather than any one image. That + matches what the old platform emitted, a blocks-gallery-caption inside the gallery's own +
    , so a caption that came across as trailing text is restored to the element it + was. Attributing it to the last image instead would change what the post says. + + The reset already sets figure { margin: 0 }, and the theme styles figure > figcaption, so a + set caption inherits the site's caption appearance. It still needs one rule of its own, in + assets/css/extended/custom.css: the gallery is a flex container, so without a full-width + basis the caption packs onto the end of the last row and reads as a caption for whichever + image it lands beside. Do not remove that rule as redundant with the theme's. +*/}} {{ $p := .Page }} -
    +
    {{- print .Inner | $p.RenderString -}} -
    +{{- with .Get "caption" }}
    {{ . | $p.RenderString }}
    {{ end -}} +