I think there's probably a case for some regulation to force at least a minimum set of open standards, because that would make it possible to e.g. switch between systems based on intermittent renewable generation etc.

Also there's the variable-speed furnace/AC fan. These heavy bastards, with an add-on brain, are very expensive when they go bad. In my case, the brain part was fine, but the fan motor died. They wouldn't sell me just the motor, just the combo for $900US! And, if I install the combo, it voids the warranty. (I did install it, I'm the homeowner not a repairman.)

I was also told if my unit was a Trane, they weren't allowed to sell me the combo! (My unit is a Goodman.) What a rip off!

You think this is bad? Try swimming pool equipment.

I think home EV charging equipment is heading in the same direction as well. Very few have local and open APIs and instead depend on the vendors cloud service for control.

I don't know where you live, but in Europe there is a standardized backoffice management protocol that you can link up to basically anything in modern chargers. Except the cheapest of the cheapest.

I have mine running through EVCC.io, setting it up was as simple as throwing that thing in a docker container and figuring out the IP address of the chargepoint.

Does this necessarily go through a third party server, or can it all be run locally?

Agreed, I couldn’t find a reasonable choice and ended up making https://github.com/jagheterfredrik/wallbox-mqtt-bridge

There is OCPP (Open Charge Point Protocol). There's quite a bit of choice in supported wallboxes. Here is Europe at least.

Yeah, but EV chargers are not that complicated. They are just smart contactors, with maaaybe some load management (EVSE can command the vehicle to reduce the charging rate).

Worst case, you just buy another one. It'll set you back a couple hundred dollars. Unpleasant, but not a big deal.

Air conditioning systems can easily cost more than $10k.

> (EVSE can command the vehicle to reduce the charging rate)

That's just a PWM signal on one of the pilot pins, it's not even that complex.

I am confused - aren't these boxes basically fancy three phase outlets? They probably have some safety fuses and some comms equipment, but the 'core' of the system is basically copper wire that connects you to the grid.

> aren't these boxes basically fancy three phase outlets?

That entirely depends LOL

So for AC chargers you are correct - 1 or 3 phases that go through a relay and, where required by code such as in Germany, a DC-sensitive RCBO, plus a small control board negotiating with the vehicle and monitoring voltage/current on one side and, again depending on where required by code, negotiating with the grid operator.

DC chargers are one hell of another beast, these have to contain all of the above plus powerful rectifiers, smoothing capacitors, EMI compliance...

Here in the UK at least they're generally single phase and required to moderate the power delivered to the vehicle based on the current electrical load in the house because most properties have quite low main cut-out fuse ratings. Bonus complications if you have solar or want any kind of access control.

At least swimming pool equipment is mostly just turning things on and off. If you look at the controller board for any given pool "timer" it's just a bunch of relays (for the pump, lights, and valves/servos).

Temperature sensors are all standardized for the most part (well, they don't seem to be anything special) but I'm not sure about chlorinators... Mine has a strange (electrical) connector and 100% proprietary threads on the PVC connectors (that were easy enough to reverse engineer in OpenSCAD: https://www.printables.com/model/24144-t-cell-cleaning-stand).

Fortunately there's plenty of 3rd party competition for things like that. Even though I had a Hayward system I was able to purchase a compatible chlorinator off Amazon for a fraction of the price Hayward was charging.

I just spent an afternoon recreating the custom threads on a Hayward chlorinator for my dad so I could 3D print a temporary replacement part. These don’t even use standard pipe fitting thread. -_-

Both of these examples, and others, sound like an underserved market.

Exactly. This is what happens when a market is so small they can overcharge for terrible technology.

I figure a couple of SWEs could make a startup that completely disrupts these industries with objectively superior technology.

Technology doesn’t matter, it’s all about relationships between dealers and manufacturers (or dealer/distributor/manufacturer, I am unfamiliar with this particular industry.) That holds true both for HVAC and pool equipment (and fire alarm systems, irrigation, etc etc)

If you can’t sell your product to the dealers because there in bed with the incumbents and the incumbent products generate service call work for the dealer, it doesn’t matter how good the tech is.

This is a people problem, not a technology problem. It can’t be solved by a couple programmers.

You offer direct to consumer sales and cut out the dealer-distributor corruption pipeline - like Tesla, Nest, etc.

Pool equipment isn’t usable out of the box like a car or a thermostat, someone has to install it and service/maintain it.

Unless you want to build your own nationwide network of installers, you’re relying on third parties who already have existing relationships with pool equipment suppliers, which is why I said it’s a people problem and not a tech problem.

You think that’s bad? Try tanning bed control equipment.

Tell us about that!

I am looking at replacing my A/C system, and having worked on the single stage single speed one that's currently installed, and looking at the insane shit everyone ships that's more complicated than your basic gas forced air furnace coupled with a single stage 16 seer A/C unit, there's no way I would ever buy something else. Every parts house has got inexpensive replacements in stock for the simpler units and service is easy; good luck if you have go find the unobtanium variable speed motor or control board that Lennox or Trane just happened to stop making the moment your unit stopped working.

Largely my take as well... I just want the simplest thing that works at this point... I'm heading in that direction as I need to replace appliances as well. So far this year, the microwave, range and dryer have all died. The microwave was the single biggest safety hazard I've ever seen, and they say you shouldn't work on them yourself... what happens when it turns on if the door is open? Or, you discover later, it's actually just on all the time even though the light is off and the fan isn't running.

I'm all about stupid, but repairable appliances now.

Yep, and it's annoying because variable speed units themselves are _better_ than the old classic one or two-speed units. They are more economical, quieter, and mechanically more reliable.

But the insane control systems compensate for it.

It just takes time for all this stuff to iron itself out. Consider how long it took for practically every heating and A/C system to become largely the same.

The problem with having standards for this kind of thing is that different units have different needs for communication and different levels of being smart. For example, some units want 2 temperature sensors and some want 3. The method used to control the system can be relatively complex - some systems are using physical models of the characteristics and positioning of sensors to do fancy control, and there are probably at least 5-15 data points involved in a typical system.

While it would be nice for the protocol to be documented (would realistically only be used by a very small number of users), the only real way you would be able to get a standard for something like this to work is if you went the Bluetooth route and did generic scenario-based profiles (e.g. HFP, A2DP, SPP), and optionally some "GATT" or "generic attribute" parameters. However, as we see with Bluetooth LE, everyone just uses GATT and implements their own little proprietary thing over it and you're back to the same problem.

Some of these systems attempt to be "smart" and just use the 24V C/W/Y1/Y2 etc protocol as a "standards compliant fallback". You don't necessarily lose ALL of the smarts, but the unit has to essentially use physics magic to make an educated guess about the information (for example, if you use a on-off thermostat, you can't really measure the temperature of the setpoint, so you don't know how close you are unless you somehow make an observation over many cycles.

I think that reasonable attempts to address this problem could involve some kind of extension to the old 24V interface - say, by offloading the actual "policy" part of system control to the "thermostat" i.e. have something that goes from 0-10V where 5V is off, 0V is full cooling and 10V is full heating. This allows you to choose your own temperature sensor situation, but complicates setups where more than one zone or thermostat is required. Of course, it will be very difficult for the industry to settle on a solution to this. Qualcomm's Quick Charge 2.0 was a very simple protocol similar to this, which was essentially self-documenting and not something that needed versioning, but of course, needs changed, 3.0 came and went, 4.0 came and went, and by the time USB C and USB PD came around you ended up with a full on data protocol API with all the OSI layers and of course, vendor specific extensions.

You could define some complicated protocol where you don't conform to a standard but you publish an API for your system (of course, there is no incentive to do this), and larger vendors like Control4 or Lutron, Crestron can program their products to interface with it. Unfortunately this doesn't allow the customer full choice over thermostats, because now you have to deal with N vendors x N thermostat vendors, which isn't scalable and you'll end up in dependency hell.

The closest thing I can think of to a standard, and the way it is solved in larger buildings, is through something called BACnet. It appears to use the Bluetooth model of "scenario based profiles", with all of the disadvantages that come with that, but the primary disadvantage is that it has to be to some degree manually configured to route data where it needs to go - and I don't think this is something installers are currently equipped to do at home scale.

Realistically, the "thermostat" is just a vestigial component in modern terms and really, it's just a user interface and thermometer now. Without getting into the wish to have open sourced app control or whatever, it's hard to define what the "thermostat" does and what the "system" is doing, and whether the device that sits on the wall is really a "thermostat" deserving of being interchangeable anyway. I have heard from a friend that does home automation integration that many clients don't like the default thermostat because it doesn't look very aesthetically pleasing. In this case, I'm definitely sympathetic to the need for customizability but it seems difficult to achieve in practice.

Make it a certification requirement (UL or whatever) for the manufacturer to maintain a gold-level OSS Home Assistant integration, and all those problems would solve themselves in a heartbeat.

Alas, vendors that interface with customers do not sell appliances - they sell "solutions", specifically solutions to the problem of their own making, i.e. them inserting themselves between the buyer and the appliance they're buying.

> The problem with having standards for this kind of thing is that different units have different needs for communication and different levels of being smart.

There really is nothing complicated there. I have some background in lift (elevator) systems, and they have similar requirements. Modern lift systems use variable frequency drives for smooth start/stop, and they came up with compatible protocols that allow users to mix-and-match controllers.

In the end, there just needs to be a simple protocol to command the motor to run at a certain speed. It can be CAN-based, it can be based on RS-485, etc. For additional smarts, throw in readings from the sensors inside the AC units (pressure, coils temperatures).

Then the control units can be made by third parties. They can do all kinds of prediction-based logic, complicated PID controllers, whatever.

> Some of these systems attempt to be "smart" and just use the 24V C/W/Y1/Y2 etc protocol as a "standards compliant fallback". You don't necessarily lose ALL of the smarts

You actually do with TRANE units. They become completely dumb, not even 2-stage emulation.

> The closest thing I can think of to a standard, and the way it is solved in larger buildings, is through something called BACnet.

I have BACnet at home, for wired temperature/humidity sensors, the same RS-485 network is also used for Somfy shades ( https://github.com/Cyberax/py-somfy-sdn ). BACnet is a low-level system, and it needs higher-level profiles. But yes, exposing the motors and the sensors inside the AC units over BACnet would be a great start.

The idea of anything with permanence involving Bluetooth gives me a brain cramp.

Are you a lobbyist? You spent so much effort arguing for something OP has shown to be just plain false.

Any tablet worked. The only reason it die not work ootb were completely arbitrary restrictions.

The control boxes can do whatever complicated things they want. But the interface to control them should and can be standardized.

I agree that it should be standardized, but not with your argument.

Yes, any tablet worked, but it required running an app customized for the hardware. That only proves that we can standardize at the level of Android app APIs.

No need for an asteroid. Just a few salty lawyers.