Tstat logging


I have been wondering how I can determine how long a day my furnace runs.

I have an Elk M1 with an RCS40 TStat connected via rs485.

It would be really nice to know how much time at the first and second stage the furnace has run, but I will be happy with findin out the total per day.

Thanks in advance

Jeff T
I use the relays on my RCS thermostat controller to operate pairs of 12V relays. One relay in the pair controls the furnace as usual. The other relay provides an input into my automation system Once per minute the system checks to see if the relay contact is closed and increments a counter if it is. Additional math functions break the minute count into hours and minutes.
I have similar issues and didn't see an easy way out that I liked.

RCS TR-36 and 2 TS-36 Stats on a ZC6R zone controller - not supported by RCS or Elk.

Today it's still running of a Linux-based system (home grown) because I do the tracking of the mechanical side, handle automatic setback and the fresh air vent.

I'm doing the embedded software for an existing commerical hardware module that will allow bridging of Elk RS-485, RS-232 and Ethernet. The specifics for the RCS implementation (to cover what I need):

- Listen/respond to Elk Climate commands (set points, mode)
- Notify Elk of changes (Climate responses)
- Emulate a "Type 2" Input module to report back Heat1/Heat2/Cool1/Cool2/Fan/EHeat/Vent, zones and electronic air cleaner status
- Listen to "Type 3" Relay commands to handle Vent and Setback
- Speed up polling for devices (30 second delay isn't acceptable)
- Listen to date/time commands and forward updates to RCS
- Pull outside temp from a ZTS and forward to RCS

I could do this on the Serial Expander but I think Elk might get upset with 3rd-party firmware releases. Today I have all the Elk protocol working but I'm doing a new ALC bridge first because it is more annoying.

Anybody interested when I get this running? Feature requests?

When the Serial Expander is polling the RCS device(s) it doesn't know how many it needs to poll - so it polls everything (Addresses 1 through 16) and to get all the data it must make 2 different queries.

My timing of the polls shows that it launches queries just under a second apart - 32 queries for the entire sequence.

Restated, it should probably be "can take up to 30 seconds" for any local changes on a tstat to be reflect in the Elk.

There is also a point where you can poll the RCS too fast and it stops handling HVAC-related issues and spends all it's time communicating - I'm obviously not going to poll that fast but my goal is about 200ms apart so for a typical 2-3 stat install the response time is within a second.

The delay I don't believe matters as much when you are simply reporting temperature and setpoints but it matters when you are tracking runtime on the unit.

I thought that when a thermostat changed a value that it immediately and proactively sent the change down the RS485 Bus. When I make any change to my RCS stats now my stargate announces the new setting immediately. At most there is a 2-3 second delay but nothing like 30 seconds! Why is the Elk polling instead of responding to realtime input from the RS485 bus?
RCS (or any RS-485 based system) is purely a polled system - the nature of the bus dictates there can only be one active "talker" so the master sends a query or command and waits for a response. After a response or a timeout with no response it moves on to the next device.

It sounds like Stargate just has a sane polling period and you've probably told it how many/addresses of tstats it needs to talk to (or it learned it) which allows it to focus on the real devices and not deal with timeouts for non-existent devices.

Even the Elk comm bus is polled - but it uses some address tricks on the embedded processors that aren't available to a normal PC serial port to poll extremely fast and keep track of packet delineations. (9 bit addressing and idle detection for those that are interested).

You do define RS485 devices in Stargate so if it is polling it only has to go through what is actually there. On the other hand, I have 8 RCS thermostats, 3 RCS LCD Keypads, and 7 RCS LED Annunciator/Keypads on the RS485 bus with no serious delays. If I change a thermostat or push a keypad button the response is immediate. The 1 or 2 seconds I sometimes see for voice confirmation is in the voice board, not RS485 latency.
I had the RCS keypad protocol documents at one time but couldn't find them for reference just now.

From memory they had a very concise poll/response (just like the Elk 485 bus and OnQ ALC) so in reality you shouldn't notice any latency. From "press" to "report" is probably under 500ms for all the devices on the bus.

Back to where this thread started - that is one of the current issues I'm addressing.

My HVPro updates TStat changes within a second (usually looks instaneous to me). I just monitor those changes to monitor runtime (simple macro that compares setpoint versus actual and determines if it's running. If yes, resumes the timer (which reports each morning and resets)). I looked into wiring into the relays on the HVAC zone controller and decided it wasn't worth it - this gives me good results.

Only drawback is I can't see if there is an issue with the HVAC system. If I was monitoring the relays, I could compare setpoint vs actual vs relay position to ensure HVAC was running when it was supposed to. Not a big issue but would be nice to have I think.
bfisher said:
Only drawback is I can't see if there is an issue with the HVAC system. If I was monitoring the relays, I could compare setpoint vs actual vs relay position to ensure HVAC was running when it was supposed to. Not a big issue but would be nice to have I think.
If it makes you feel any better, even monitoring the thermostat control lines doesn't give you any confidence that the unit is really running, just that it is supposed to be running. I did put some 24 VAC relays to monitor what my system is supposed to be doing for logging purposes, but I think the next step up is to add some combination of current draw meter (i.e. fan/compressor is running within specs), a sail switch (i.e. air is moving) and/or extra temp probes on the coils.