Yes, client and server can run together on the same HA installation or separately.
Okay, well, I’ve hit a bit of a thing. Apparently the 482 does not support scenes or setback control (the home/away/sleep thing). It can change the heat/cool setpoints in the setback modes, but not actually make the thermostat go into those modes, like for an automation where you want it to go into away setback when nobody is home, or go into “sleep” setback with a night automation.
So I’m curious what everyone else is doing: just using schedules, using scene control, or both, or none. What I was hoping to do personally is have Home Assistant trigger “day” and “night” scenes, and a third “away” scene depending on time or triggered by other conditions. Of course home assistant can just as easily command setpoints through automations, so I wonder if it’s worth the effort to dig further into the no scene support issue.
This is different from setpoint groups, which the 482 does support. The 654 snow melt and 161/162 setpoint controllers use setpoint groups. I don’t have any of these three but the 161 is inexpensive enough that I might pick one up to make sure setpoints work OK.
EDIT: This forum is horribly inconvenient to provide progress updates since it blocks me from posting more than 3 replies in a row unless other people comment in between, so I’m not going to post progress updates here anymore.
EDIT 2: Created a discussion in github for updates:
Hi,
I am looking into how this works. I read a bit about CAN bus, I actually am curious if the 482 is even really necessary. For 2 wire can bus you can directly turn the can bus into an RS232 cable and read/write the data off of a TTY port for example.
I strongly suspect the same is true of the 1 wire canbus.
would someone be willing to take a hi res photo of the 482 circuitry so i can have a look?
Good reference on 2 wire canbus: CAN Bus Wiring Diagram, a Basics Tutorial | Tek Eye
I think the idea is 2 wire can bus you have a constant voltage on each wire, when a bit is transmitted, one wire (the high one), has a high voltage, and the low one has a “low voltage” the difference in voltage is a specific value.
I assume (without reference), 1 wire can bus is just the obvious analog signal (high for a 1, low for a 0).
I’m looking for a reference on 1 wire <-> 2 wire canbus…
Also, after a bit more digging, one wire CANBUS is called “SWCAN.”
Per the tekmar docs, the internal tn4 runs at 400 baud.
I suspect this hardware can read it directly:
The 482 is actually not a converter; it’s an application server. When you communicate on the RS232 port it’s really working with the gateway’s internal application database. In the background the gateway will work with the bus or give immediate responses to things it already knows (commands can also delay fail like if you sent it something that conflicts with a device setting, i.e. setpoint out of range). The 232 port is never actually connected to anything on the bus and vice versa. Everything is moderated by the application running on the gateway (the 482 has 5 discrete tN busses it can contend with).
Of course you could try to reverse engineer the application server by listening to both sides since it’s not encrypted, but whether or not that’s worth the effort vs. buying a gateway is debatable. I assume the motivation for trying to get around using the 482 is because it’s expensive. It’s obviously targeted at automation systems like Control4, Crestron, Savant, etc. where another $1000 to integrate your HVAC controls system isn’t really a big deal.
Yeah i get that. I guess thats one obvious thing, but, more what i was thinking was, if you wanted to build your own thermostat on the network for example. Or even just install one of theres but avoid running all the wires from that thermostat to a tn4 device on a different floor. You could just transmit the CAN Bus over wifi.
I’m waiting for you to release your code (in whatever state) then I will buy a 482.
Uploading my tekmar-482 integration and tekmar-packetserv add-on to Github.
Sample entities from the first release:
I see that the packet server Python code on your github is a modification of the Tekmar sample code, with an HA wrapper around it.
I’m wondering: can that Python code be run stand-alone, without the HA wrapper? And then have the 482 integration just point at that packet server?
My HA installation can’t have a direct serial cable to the 482, due to house layout, so I need a separate device connected to the 482 via serial. I could use an RPi with a separate HA instance on it, but I’d really rather not have to spin up a whole second HA instance just to run this - if I could just run the RPi with Raspbian and have the packet server running on that, it’d be easier…
I have the same layout where my HA server is separate, so I have a Pi 3A+ in the garage with the USB serial adapter connected to the 482. It just runs the add-on and a simple config. I’d like to do more with the add-on format such as auto-detection and auto-configuration in the future.
If it’s easier for you to hack it up and run it separately then go for it. It was less work for me to make it Home Assistant add-on, probably easier to support because I know the add-on package isn’t going to be changed by the user, add-on environment doesn’t change, updates and backups are easily handled by the supervisor, and I didn’t want to make a Home Assistant thing that required going outside of the Home Assistant ecosystem to use it (except for the required Tekmar hardware).
This is my minimal configuration.yaml on the Pi 3A+:
# Disable default config
#default_config:
# Minimal config for tekmar-packetserv
config:
frontend:
system_health:
usb:
Form topic for the Tekmar 482 integration and add-on:
Hi There
New to Home Assistant. Came with the specific purpose of using your Tekmar plugin. Have a raspberry pi 3b running the lastest version. Have Home Assistant loaded with the Tekmar Packet Server - no issues. Connected to my Tekmar 462 Serial with a USB Serial and have that selected in the config. My version of the Tekmar Packet Server had a grey line underneth which says Allow IP access* and then 0.0.0.0/24 This is a required field. I am unsure what this should be. If I type in the address of the pi, the logs show that a connection is not established. Sorry to be so thick - but I could use a suggestion here please.
It’s a security feature, but if you don’t need it leave it at the default 0.0.0.0/0
If you still need help getting it set up, please post some screenshots in the topic for the integration (Tekmar Integration and Add-on) or in the discussion board in github: Discussions · WillCodeForCats/tekmar-482 · GitHub