Tekmar heating controls, Fujitsu split A/C

[mik3y (mikey)]

@Juliean_Galak

The protocol you linked, Tekmar Home Automation/RS232 protocal is the serial protocol for communicating with the Tekmar 482 gateway. You have to buy the gateway and connect it to your other Tekmar devices.

The protocol used by the actual thermostats and such is the tekmarNet protocol mentioned at the top of that page - a CANBus-like protocol which, afaik, has never been published. I suppose it’s possible to sniff it and reverse-engineer it, to avoid having to buy a 482, but that’s well outside my skills.

Oh, thanks! Well, that certainly complicates things, and certainly saves me some time. Hmm that’s a bit more challenging. Spending 1k to sniff a canbus is significantly less exciting… but then again so are all my other thermostat options, hrm. ebay saved search for cheap used 482, activated…

@Juliean_Galak

The Particle project you linked seems to be for Mitsubishi, not Fujitsu heat pumps?

One of my biggest questions with the Fujitsu units is whether they have an exposed serial (or other) interface that can be connected to and would allow control of the unit. I know there’s a serial communication channel between the indoor heads and the outdoor condenser units, but I have no idea if that’s also usable to control the whole thing, or, for that matter, how to physically tie into it.

If you’ve done this with the Fujitsu units, could you share the hardware details? What did you plug in where?

Oh gosh. That’s an even more embarrassing miss… you’re right, wrong manufacturer.

The Mitsu units have a diag port that is the same (or similar) on most of them. I’m not sure if was originally intended for consumer-facing add-ons, but it supports all of the same controls that the IR remotes do. You can see an open thread here on the upstream library where some folks have shared photos of where they’ve tapped in.

For Fujitsu, that’s interesting about the indoor/outdoor bus. I would not be optimistic that it’s connected to (or even the same protocol) as what you’d need for the “frontend” controls, but that’s pure speculation on my part.

[Juliean_Galak]

@mik3y

The Mitsu units have a diag port that is the same (or similar) on most of them. I’m not sure if was originally intended for consumer-facing add-ons, but it supports all of the same controls that the IR remotes do. You can see an open thread here on the upstream library where some folks have shared photos of where they’ve tapped in.

For Fujitsu, that’s interesting about the indoor/outdoor bus. I would not be optimistic that it’s connected to (or even the same protocol) as what you’d need for the “frontend” controls, but that’s pure speculation on my part.

Yeah, I doubt that bus is what I want. I jus t know it exists from reading what little service literature I’ve been able to find.

The indoor units have all sorts of connectors, so it’s quite possible that one of them gives some sort of external serial access, but I’ve found almost zero info on it and don’t want to just randomly probe them…

My next attempt is going to be via IR. I read somewhere that the Fujitsu units actually broadcast IR responses when receiving IR commands. I’m somewhat skeptical of this, but for the cost of an IR reciever module, it’s worth investigating.

Controlling them via IR isn’t a big deal, but it’s the lack of feedback that’s been the killer so far. I want to know whether the command went through or not…

[Glendale]

Okay, I’ve decided I’m going to buy a 482 and try my hand at an integration for Home Assistant. Over the last year I’ve been working with a Solaredge integration so I’ve been getting more comfortable with HA integrations and Python in general, although I’m far from an expert I think I know enough at this point to at least give it a shot. I already have a 486 but there’s no indication that’s going to open up with an API.

Obviously the 482 is expensive ($980 from supplyhouse.com) and that will probably limit a lot of people, but if anyone is interested I will share the github link here once I have something worth sharing or just watch for it: WillCodeForCats (Seth) · GitHub

Edit: I decided to just make an empty repo to start with: GitHub - WillCodeForCats/tekmar-482: Home Assistant integration for the Tekmar 482 Gateway

[Juliean_Galak]

Awesome. Eagerly following for developments. How do you plan to connect to the RS-232 interface on the 482?

[Glendale]

I’ll try a USB serial adapter first to keep things simple. I use Perle or B+B SmartWorx serial servers in other applications, so I’d probably investigate those next.

[Juliean_Galak]

My thought had been an ESP8266 or ESP32 device to access the port, and just pass raw data back and forth to HA. But there are many ways to accomplish it.

[Glendale]

The direction I’m going right now is an add-on and an integration. The add-on connects to the Tekmar gateway with a serial to USB adapter, and the integration will talk to the add-on over the network.

I’ve never made a HA add-on before, but so far I’ve managed to get something working where I can send/receive commands to the 482 in hex characters using “netcat” (nc).

Edit: The add-on will be here: GitHub - WillCodeForCats/tekmar-packetserv: Home Assistant add-on for the Tekmar 482 Gateway

[MaxL (Max)]

I am just starting out on the same journey. Very very new to HA, but very comfortable with Python, analyzing protocols, sniffing packets, etc.

I have a few Tekmar 561 t-stats managing a 306V Zone Valve Control. I manage the heat via a Watts Home mobile app. Was about to sniff the WiFi traffic to/from t-stat to see if I can maybe convince the wifi thermostats to talk to a local server instead of whatever online thing they are talking to right now. Not sure how good my odds are here, but it will be fun to try to reverse engineer the protocol.

Questions:

1. Looked at the 482, but appears unable to control 561s or the 306. Does anyone know if that is an accurate assessment?

2. If so, currently looking at 486, which is even more expensive, but has a lot of nice features, it appears. Does anyone have any experience with that one?

[Glendale]

The Gateway 482 and 486 only works with tekmarNet devices (which is a wired bus). Neither the 306 nor 561 supports tekmarNet. I see references to tN4 on the wiring for the 306, but it appears to only be used for “away” setback, not full communications.

[MaxL (Max)]

Where are you reading this? The only thing I see referencing 306V is this drawing:

[Glendale]

Try it and let us know.

[Glendale]

From what I can see is that the 306V will pass through tN4, but you still need tekmarNet thermostats (hence the dual labeling of the away/tN4 terminal).

I figured I should share what Tekmar models I’m working with:

• Gateway 482
• Thermostat 557 (fan coil zones with A/C)
• Thermostat 532 (hydronic or heat-only fan coil zones)
• Universal Reset Module 423
• Zone Manager 335

I bought both the Gateway 486 and 482, but the 486 appears cloud-locked as far as I can tell, so all of my efforts will be focused on the 482 unless someone can figure out how to get a local interface on the 486.

[Glendale]

Progress update: Server add-on is done and I have a working test client. The server add-on is running in Home Assistant on Pi 3 A+ with a USB serial adapter connected to the Gateway 482. The next step will be to start working on turning my test client into an integration for Home Assistant.

Here’s what my test client data looks like:

And what the test setup looks like (eventually I’ll connect it to my real system):

[Juliean_Galak]

Very nice! I have a similar setup in my house - 423 Universal Reset Module, 335 Zone manager, two 325 Zone expanders, and 552 Thermostats throughout the house. So I’m very eager to see what you are able to accomplish.

Regarding the 486, afaik, it’s cloud only. There was another unit, the 485, that had local web control which might have been scrapable, but it was discontinued. You can find it as NOS, but I see no point in developing towards discontinued hardware.

I do have one request: as you are developing this, please consider making your architecture such that it’ll be possible to add physical separation between the 482 gateway and the HA server. You don’t need to code that, just leave in a layer of abstraction in the code for that to be added later. You may already have done so.

For me, for example, there’s no good way to connect it the way you have done it. I’d need some sort of wireless sender at the 482 gateway (ESP8266 or equivalent) and some way for the HA integration to receive the data from the sender.

[Glendale]

It’s already working physically separated with the Pi 3 A+ is connected wirelessly to LAN.

[Glendale]

It’s already a client/server. I made an add-on for the server, and then a separate integration will connect over the network to the server. I’m using a Pi 3 A+ to run my add-on which talks to the 482, then the integration will run on my actual HA server in a different part of the house connecting over the network. In my screenshot the test client you can see is running on MacOS, which is my desktop computer, not the Pi connected to the 482.

Here’s pictures of the completed server add-on:

[Glendale]

Slowly making progress, here’s some first run entities working:

I had to delete one of my other posts because this thing doesn’t allow more than 3 posts in a row.

[safadig (Gus)]

This is great work. Thank you. I have a 482 connected to snowmelt system. The RS232 is linked to control 4 but is only giving me the open/close status for the tekmar 654 Thermostats (OFF/Melt). Can’t wait to test on my end. I have my RS232 end next to my Home Assistant so I assume I can just use the RS232 to USB and plug in directly

[NigelHA]

I looked at the Tekmar Python-based packet server implementation and it makes use of threading, so would not really be well suited to the limited constraints of an ESP8266, even the ESP32 micropython implementation is tied to a single core. You would be better off taking the Pi route, even if just a Pi Zero 2 W as that is quad-core.

[Juliean_Galak]

My thought was to use an ESP as a pass-through for the serial connection, and do the actual processing elsewhere.