For places where Natural Gas detection and alarming are starting to become a thing (whether required by law or otherwise), what are you folks using for system-connected fuel gas detectors, especially in applications where sensitivity and application flexibility are needed?

I ask this because UL2075 listed fuel gas detectors seem to be scarce options-wise:

• Macurco makes both the GD-2B, which is cheap and cheerful, and doesn't require commissioning labor (it wires up just like a system-connected CO detector does) but doesn't conform to the current UL1484 10% LEL threshold due to how long ago it was UL2075 listed...
• and the GD-6, which can be commissioned to meet that 10% LEL threshold but turns itself into an expensive brick after a mere five years as the pellistor (catalytic bead) gas sensor in it is soldered-in and thus nonreplaceable.
• Then there's the Honeywell Sensepoint XCL, which at least has replaceable sensors, but like the Macurco detectors, leaves you with only two relays at most to play with locally (in addition to 4-20mA and RS-485 -- you could bolt on a 4-20mA trip of some sort to get more relays but that's its own hassle, especially since UL listed trip amps are harder/costlier to come by than they should be when you only need 1-2 outputs)
• Belimo also makes methane detectors that are UL2075 listed (by CSA) but a) doesn't sell them in the US and b) has a goofy-aah caveat in their NRTL listing that their detectors aren't suitable for life-safety alarming (I think it was required because you can't commission their CO monitors to meet UL2034 time-weighted/integrated CO alarm thresholds, but it's a real downer in other applications, including where low-level CO monitoring would be useful)
• MSA Safety makes the SMC 5100s which are UL2075 listed for methane, but they are in Ex enclosures (which look far out of place in anything that isn't industrial) and terribly expensive as well ($multi-thousands, partly due to paying for an Ex rating you won't ever need)
• and that's all I've been able to find -- everything else that's NRTL listed I've seen, best I can tell (as FM listings are unhelpful on this front) is only to UL/IEC61010, which doesn't satisfy NFPA 715. That is based on my best interpretation of the 4.3.1 listing requirement, in light of it being a port of NFPA 72 10.3.1, which requires FA equipment to be listed specifically for FA service, not just to general electrical safety standards.

(Dishonorable mentions to Senva and AGS, who obtusely try to hoodwink people into thinking a UL 2034 or 2075 recognized sensor in a UL 61010 or unlisted monitor is "good enough", and also don't understand what trouble outputs are for.)

I've seen this impedance-mismatch a couple of times now in a couple of different spaces (ALPR, visitor management) but it seems to be a recurring problem: many/most? webhook/event-action implementations only support POSTing at things, while the boxes we know as "webrelays" (ControlByWeb's stuff, Viking RC-4As, and so on) only handle HTTP GET requests.

How does one deal with this incompatibility? Is there another vendor I should be looking to for webrelay-type boxes that can handle being POSTed at? (Axis comes to mind but using raw VAPIX from a webhook seems to be quite the affair. I'd much rather have something simpler if at all possible, especially considering some webhook implementations don't provide a great deal of control over request bodies.)

I'd rather also avoid sending raw TCP over the wire because that's a) not compatible with encryption and b) not always supported by vendors (Vaxtor does this on the ALPR side, but it seems a lot of more enterprise-y stuff doesn't provide options for other protocols.)

So I've been all over the place (finding pretty much every vendor I can dredge up, from North America, to the UK, to Southern and Eastern Europe, and even the Far East), researching multifamily/multi-unit intercom (doorphone, entryphone, "buzz in") access control systems, and it's been a frustrating experience for five reasons:

1. Input supervision (or lack thereof).

Why is it, out of the dozens of vendors that offer intercom access controls, that only Commend and Axis even sort-of-get the notion of EOL-supervising inputs? Even the stuff from Axis' sister company 2N can't seem to interoperate with the Axis network relay modules and their supervised inputs, nor provide their own supervised input solution, which really does no favors for the 2N Access Controllers, or really any access controller made by an intercom vendor for that matter.

2. Vendors that still don't offer remote relays in the year 2026.

(cough DoorKing hack Security Brands (and several other gate-intercom vendors as well as some of the more niche US door-intercom players) wheeze) I should not be able to defeat your access control system with a screwdriver, or worse yet a ten-second nondestructive attack on the cheap wafer or tubular core securing your intercom's enclosure, combined with a humble paperclip.

3. Built-in readers that are relics of yesteryear.

Some vendors (sighs Viking...) are still on 125kHz prox; many others do bother with 13.56MHz MiFare and even DESFire, but those that do don't provide documented support for custom keys (which is a major integration issue in mixed environments), nor do most of them (Axis and 2N are the notable exceptions to this that I know of offhand) support OSDP as of right now. (At least BAS-IP, Mircom, and a couple of other vendors have remote Wiegand interface modules that talk over some other protocol that's hopefully more secure.)

What aggravates this is that it's not like you can get many intercoms these days without that built-in reader module. Even DoorBird, who offers an option in their configurator for a third-party reader opening, still insists on dragging the built-in reader into the package if you do that, as far as I can tell at least. (Commend gets it right with their reader-as-matching-external-module approach, which even supports OSDP, and Elvox/Vimar intercoms also provide sane provisions for third-party readers.)

Hopefully we'll see PKOC and/or Aliro start to gain traction in this market at some point, as either of those would at least get us to the point where a mixed reader environment is more practical.

4. Expecting to be the center of the universe in other ways.

Lack of software integrations and documented APIs (Axis, 2N, and to a lesser extent Commend, BAS-IP, and DoorBird are the standouts here, with everyone else lagging behind as far as I can tell), management interfaces and configuration manuals that assume that your intercom doors are all that matter, proprietary support for mobile entry that can't be used for non-intercom doors as well due to the lack of a suitable standalone reader, providing your own pseudo-solution for lock backup battery instead of accommodating users who want to bring something actually fit for their usecase (hi, Mobotix!), and the list goes on I'm sure.

And that's before you get to vendors that can't talk standard SIP for some reason or another.

5. Accessibility issues.

Some vendors don't provide T-Coils for interacting with hearing aids, never mind providing support for text messaging (either using touchscreen or T9 input) or two-way video calling. And that's just covering accessibility for the hearing impaired, although the ADAAG rules in 708.4 are not helping matters by clinging to thoroughly obsolete TTY technology when they could do a lot to push vendors to more implementable and interoperable approaches -- DASMA 303 4.7.4 gets this right.

The real problem on this front, though, is visual impairments. Imagine trying to use a touchscreen while blindfolded, and you get the idea; the DASMA 303 standard, adopted as part of accessibility codes in a few states (such as Minnesota) albeit not nationally, requires recessed or protruding physical keys in 4.7.1 as a result. Unfortunately, a lot of the top-of-the-line stuff from most vendors nowadays is all-touch, with not only new-fangled Swiftlanes and such embracing a touch-native philosophy, but most of the old-school vendors following along, and making features available in their touch intercoms that aren't available anywhere else, or even moving entirely to touch buttons on non-touchscreen intercoms. (Even 2N, who has rather nice support for physical buttons on the Verso, has limitations on it that aren't present in the Style, and Axis doesn't even offer a multi-user intercom with actual buttons on it as far as I can tell.)

And that's before you get into speech synthesis -- Came-BPT is the only vendor I know of that provides support for this, even though it'd be quite helpful overall, I'm sure, especially when combined with a motion sensor trigger to keep the intercom from nattering on to nobody in particular.

Are my expectations too high here?

Overall, can someone tell me what is going on here? Are my expectations too high, that intercoms that are playing the role of access control should support features comparable to a professional access control system? Is there room for a player in this market who actually cares about security beyond the obvious features of vandal-resistance and cybersecurity architecture, never mind providing full-spectrum accessibility support even if it means the unit isn't the sleekest?

In the OSDP specification (as far as I can tell, I've only seen up to 2.1.5), Function Code 6 in the Annex B list of possible capabilities for a reader to report only defines display size values for 16x1, 16x2, and 16x4 character LCDs. However, there are several vendors out there who make OSDP readers with displays of other sizes, whether it be something like a 20x4 character LCD, or even graphical LCDs, some with touchscreens. (If you're wondering who, it's too long of a list to name, but it's commonly found on biometric readers, and yes, some of the big names are included, such as HID, STid, and Suprema.)

What value do these fancy readers return for Function Code 6 when asked for their capabilities? Do newer versions of the OSDP standard provide more standardized return values, or is there not even a de facto standard for fancy readers to return?

Now that we have the text/video communication requirements to worry about, several elevator communicators have come out that natively speak SIP on their Ethernet port:

• Commend's id5 TD CM
• LiftComm's TEC-1400EAV
• 2N's Sentrio
• and the Hubbell/Gai-Tronics Hubbcom GSC4100

If one is installing a communicator like this (vs. something that uses a proprietary portal, like a Rath SmartView 2, a K-Tech Connect, or a Wur-Tec Wur-Com+), and one needs to have it call an external monitoring station (vs. an internal security desk), can the external monitoring station simply provide you with a SIP address (phone@ip.or.host) that you can configure the communicator to call directly, or do you need an ITSP (Internet Telephony Service Provider) to provide SIP registration for the communicator or otherwise act as a "go-between" between the communicator and the monitoring station?

Other than this post on the subreddit, I haven't really seen or heard mention of water hydroelectric elevators (basically, closed-loop hydraulic elevators that use a water-based fluid instead of oil) anywhere, even though the post alleges that some places still installed them into the post-WWII era (1950s-1970s).

Why is this? Were they a terrible idea? Did all of them get modernized to oil, or are some of them still chugging along on water-based fluids? And could one get a water-hydroelectric passenger or service elevator built for them (presumbly by an independent) in this day and age?

(Part of why I ask this is that the carwash people have been busy tinkering with non-oil-based hydraulic fluids using water/glycol or water/polymer mixes, and it seems that going to water-based fluid would get rid of the need for oil separators and possibly even shunt tripping, both of which have attendant headaches of their own.)

While it's generally accepted (as far as I know) that mortise locksets are considered more reliable and durable than cylindrical/tubular locksets, how do the various flavors of mortise lock compare to each other in this regard, given that all commercial-service mortise locks will claim Grade 1? Or in other words, just how do the following options rank in durability (cycle life/reliability, abuse resistance), and how far apart are they on that scale?:

• Inexpensive (value priced) commercial mortise (Marks Nova 5, Cal-Royal SC & NM, Falcon MA, and so on)

• High end residential mortise (Baldwin Estate)

• High end/institutional grade commercial mortise (Schlage Commercial L series, Corbin-Russwin FA2000 series, Best 45H series, Accurate 9000 series, and the likes)

• "High security" mortise (Securitech single-point mortise hardware, Accurate 9000SEC series, Surelock McGill Stirling series)

• And to top it off, where do detention-world mortise locksets (say a Folger Adam 9300 or Southern Steel 10500) fit into this, since they don't seem to carry ANSI Grade ratings?