Honeywell Enviracom Zone Controllers

[mitchmitchell1616]

Here is the description of the Enviracom messages that I have been using.

[DanHunter]

Enviracom message format

Good baseline for the documentation. What needs to be included is what device is sending what. For example, in your environment, the 5421 is sending the 3E70 and 3E72 messages. The 9421 is sending the 3110, 3C00 and many more messages.

My interpretation is the following: when working with a 9421/5421 system, both devices work together to perform the HVAC operations that this system is designed to perform. The 9421 (thermostat) includes instance (zone) 00 and the 5421 (controller) includes instances (zones) 01, 02, 10, 11, 41, 42, 51, AND 00!!! That is, the two devices work together and share environmental properties and controls.

It also appears that repetitive reports are synchronized and each device queitly acknowledges the other and replies via a report when needed or obeserves a change in the other's report. For example, when the thermostat issues a '3110' report, the controller acknowledges this and posts a '3E70' report. These two commands always occur together. Also, after every third '3110'/'3E70' report, the thermostat's humidity is reported via a '12A0' report after the thermostat acknowledges the '3E70' report from the controller.

Gotta go now ... will give more info later ... enjoy ;o)

[DanHunter]

31xx commands

For the 9421/5421 System, the 9421 thermostat issues a 31xx report which I interpret as a "do something" command. The 5421 controller then interprets this command and does it thing. 5421 typically responds with a '3E70 10' report which I interpret as a "start" command to some controller subsystem. Afterwards, the subsystem (heat, fan, cooling, ...) issues a status report where '3E70 11' is for heat status and '3E70 42' is for cooling and so forth

31xx commands documented so far:
3100: Equipment Fault
3110: Status
3120: Error Report
313F: Time
31E0: External Ventilation
31E3: Humidifier
31E5: Dehumidifier
31F0: Fan

Hope this helps.

Question I have is: what are all the 31xx commands that we need to find and document?
* Cooling stage 1 (via 3110???)
* Cooling stage 2 (via 3110???)
* Heat stage 1 (via 3110???)
* Heat stage 2 (via 3110???)
* Heat stage 3 (via 3110???)
* Heat stage 4 (via 3110???)
* Em heat stage 1 (via 3110???)
* Em heat stage 2 (via 3110???)
* Humidifier (31E3)
* Dehumidifier (31E5)
* Ventilator (31E0)
* Fan (31F0)

* Error (3120)
* Status (3110)
* Equip fault (3100)

I'm going to make a suggestion to start with ...
310x -> fault request
311x -> status (request for change in status, ...)
312x -> error request
313x -> time
31Ex -> humidity(vent0, vent1, humid0, humid1, dehumid0, dehumid1, ...)
31Fx -> fans (fan0, fan1, ...)

[mitchmitchell1616]

Envriacom API Demo Rev 1.07

Do you have the enviracom API demo? It will show the message and interpret them for up to three zones. If you don't have it, PM me and I will get it to you --- its too big to post here.

[mitchmitchell1616]

I assume the 5421 you are talking about is the Honeywell THM5421C1008 EIM for the VisionPro. I'd be surprised if it did anything with zones 1-9 since it does not seem to be a zone controller, but zone 10-?? seem to be special "instance ids" that change the meaning of the message.

Have you check the Type field (msg byte 7 -- ie. msg field 4) to see if it contains a 'C', 'R', or 'Q'? That would tell you if the EIM and Thermostat were sending change commands 'C' to each other or only sending reports 'R'. I think the query commands can only be sent via the serial adapter.

I think there is a pattern to the message numbers as you said, but I have not had a chance to try and figure out the patterns -- I'm just trying to get the known messages working. I do have the prototype plugin set up to log any unknown messages to a file for later analysis.

Here is an example of what I am seeing on my UI at this point, with three zone controllers (three serial adapters) controlling a total of ten thermostats.

[DanHunter]

9421/5421

The system on my bench consists of the following: Thermostat is the TH9421C1004, EIM is the TH5421C1008 ... like you thought. The 5421 is a single zone controller (like you said) and all commands between the two are 'R' (report) type. Which panel are you using, the W8835A1004? I only post on this site according to what I observe on my bench.

From what I see, the 5421 is a simplified version of the 8835 (single zone) but created with much newer technology than the 8835 (uses Atmel controller to do almost everything).

I make the assumption that the system that I have supports a subset of the entire Enviracom protocol spec and your multi-zone more of that spec. Need to go into a commercial environment, which you may have, to get a larger sampling of the spec

I will send a pm to you but this is what I have documented so far for my system:
* Honeywell uses a distributed control environment for their HVAC systems
* Enviracom is a semi-timed multiplexed bus.
* Messages are synchronous or asynchronous.
* Synchronous messages are queued and sent during their selective time slice
* Asynchronous messages are 'status' type
* Thermostat (controller) and EIM (interface) communicate via 'R' commands and use message handshaking for command ack
* The init sequence after reset for the 9421/5421 is the same as your system (per your doc)
* The EIM is split into subsystems (thread-like) that report their status on the bus with respect to their instance(zone) (this probably is legacy protocol from the old days when each subsystem (humid, dehumud, vents) had their own hardware boards and bus interfaces)
* The protocol is legacy, archaic and consumes excessive bandwidth but it works so Honeywell will keep it for now ... but it will evolve into something new to support the newer smart systems and wireless modules that require higher bandwidths and more sophisticated control (look at Johnson controls and how they integrate in a commercial environment)


Your work is awesome so far. Now try this ... unplug the thermostats from your panel and monitor the panel messages. Similarly, unplug the panel and monitor the thermostat messages. Now analyze both queues individually and with a sample queue under normal operation. Thermostats start off with 'H' commands and then the panel takes over. 'R' messages are used for control, status and handshaking.

I use AprilAire where the controller resides in a box down in the mechanical room and controls all the 'dumb' thermostats in each zone. What I like about the Honeywell system is that the control is distributed and the 'intelligence' lies in the thermostats rather than a single controller (Enviracom is more complex and possibly more unreliable at first but if integrated correctly, more robust in the long run ... which is probably why Honeywell promotes it)

[mitchmitchell1616]

On a slightly different subject -- adapter resistors

Here are some pictures a friend sent me of surgery to improve the heat dissipation of the serial adapters.

The adapters come with two 910 Ohm 5%, 3W installed which seem to be unable to dissipate the heat generated. The bottom picture is with 5W version substituted to alleviate the heating problems.

The adapter case still closes with this configuration

[DanHunter]

Does increasing the wattage of the resistor really help?

Increasing the wattage of the resistor ... does this help?

The dc voltage across the resistor is about 28V. 910 Ohm implies a current of 28/910 = 30mA. wattage is 28*0.030 = 0.8W. Resistors are rated 3W so they are running 0.8/3 = 25% of rated value. Valid design goal.

Two resistors are in parallel so total wattage being dissipated is 1.6W ... ugh!!!

If the problem of the adapter failure was due to the resistors failing, then yes, increasing the wattage of the resistor is what you need to do to resolve the problem.

If you increase the wattage of the resistors they will still dissipate the 1.6W as heat. Has anyone F/A'ed a failed adapter and know what component caused the failure? I doubt it was the resistors ... most likely another component that failed because the interior temp of the case went above the component's rated value.

To me, the best solution is to vent the case. Drill holes through the top of the case (or whatever side is facing up) and holes on the bottom, or near the bottom on the sides. Convection will create a draft and force the hot air out the top and suck in cooler air from the bottom or near the bottom where the lower holes were drilled. Or ... just leave the top off completely if you are not afraid of dropping something into the adapter.

Hope this makes sense.

btw ... the circuit design of the board is pretty much cut and paste from vendor's app notes (5V DC isolation and rs232 driver subcircuits are almost exactly those in the Linear app notes ... no optimization done on the circuit or cost reduction methods implemented).

In my opinion there is a better way to implement the front-end and eliminate the resistors (and the main cause of the heat) but I don't work for Honeywell and their market is so captive they can do what they desire.

[mitchmitchell1616]

Yes, I don't think the resistors actually fail, but they are generating the heat. They get *hot* and over time the plastic case yellows and warps.

The symptom of the failure is garbage characters on the serial port so its probably some other component that cannot take the heat.

I know others have tried venting -- drilling holes and such, but that was not enough. Mabe a heat sink is what is really needed to pull the heat outside the case.

We'll see, I have six resistors on the way and will try them in my adapters to see if they help.

Best Regards,

Mitch

[DanHunter]

Watts are watts

The heat generated by a 3W rated 910 ohm resistor will be the same as that by a 5W rated 910 ohm resistor for dissipation of 1.6W of power. The difference will be that the 5W resistor will have a lower W/mm^2 value which makes it feel cooler (larger surface area)

1) If internal ambient temperature is the cause of the failure, then increasing the physical size of the resistor will not make that much of a difference ... you need to ventilate that heat out of the box

2) If excessive PCBA temperatures near the resistors (which causes the nearby components to heat up) is the cause of the failure, then the solution is to reduce that thermal transfer between the resistors and the PCBA. Honeywell did some of this already: they punched out (cut out) the PCBA below the resistors. Other options include: stand the resistors up (like the caps); increase the length of the resistor leads and raise the resistors above the PCBA by 6mm to 8mm or so; use larger resistor packages that reduce the W/mm^2 surfaces above the PCBA or put heatsinks on top of the resistors to pull the heat up and away from the PCBA. Issue using larger resistor packages: more surface area above the non cut-out areas of the PCBA allows thermal energy transfers to still exist between resistors and PCBA

This ties into the prior email regarding F/A of dead boards. If the component failure was not close to the resistors, then the solution is to vent the box (option 1 above). If the component failure was close to the resistors and heat related, then utilize one of the solutions from option 2 above.

My take: do both (i.e. increase ventilation and reduce thermal transfers from resistors to PCBA to failed component)

Hope this helps

[mitchmitchell1616]

Well it has been a busy week so I have not made much progress.

My todo lists includes the following:

Design and Implement the plugin UI pages
Add code to handle submit actions and update config file
Add formatting routines to create messages to send to the panel
Complete connecting low level routines to homeseer thermostat APIs
Research how to make plugin support events, triggers and other homeseer functions
Work out how to handle desired states vs. current states including possibly retries etc., including handling lost change messages.
Log file management
Lots of other stuff I don't remember at the moment.

I probably have about 30-50 major pieces of code to write to get the plugin into an alpha state when I can really pass it around.

Fun... Fun...

Mitch

[paulhiggs]

I am also implementing a PC based control system and found the information in enviracom_message_format.zip to be most helpful. In addition, I am trying to decipher some of the "unknown" fields and have the following which could be incorporated

2330 Message-Set points

thermostat mode status data 5 data 7
--------------- ------ ------ ------
follow schedule 0 <period> 0
hold interval 1 0 0
hold days 2 0 <num days to hold>
permanent hold 2 0 0

[homeCanuck]

I'm working on .NET code for Enviracom as well.

Has anyone been able to disable a period through a 1F80 command?
I can easily change the schedule for a specific day/period, but I can seem to disable the period.

[mitchmitchell1616]

I haven't been able to do much on my code lately, but I will try out the 1F80 command.

[kaldoon]

Interested in the status of your plug-in? Has there been any progress?