New Firmware 3.10A old comm/time problems back

[rsw686]

The logger doesn't poll the thermostat every minute. When it connects to the controller it sends a request to enable unsolicited notifications. This is all or nothing I need them for the area, unit, zones, and message status. The controller will push notifications to the logger as events occur. This is what is happening when you see "VERBOSE: ThermostatTimer: Unsolicited status received for" in the log. If the logger doesn't receive a notification for 4 minutes it sends a request and you see "VERBOSE: ThermostatTimer: Polling status for" and "VERBOSE: ThermostatTimer: Polling status received for". If 5 minutes comes around and no status has been received you will see "WARN: ThermostatTimer: Not logging out of date status for". I didn't see a reason to poll every minute when it should be receiving the notifications, but also didn't want to log stale data.

When you reboot the controller and no time is set it must be sending a value that is out of range for the C# DateTime conversion. I can put a try/catch in there to ignore the error and set the time if that occurs.

For the thermostat logging error when set to heat/cool I haven't tested that. Both my thermostats are configured as auto heat/cool. From the log it looks like the thermostat only sends the setpoint for the mode it is currently in and not for both heat and cool. It is interesting to see the INVALID in the last column which is the hold status.

VALUES (NOW(), '1','Thermostat','OFF','70','INVALID','78','0','25','55','HEAT','ON','INVALID')
VALUES (NOW(), '1','Thermostat','OFF','69','INVALID','78','0','25','55','HEAT','ON','OFF')

EDIT:
The updated version below has settings to adjust the time sync interval and drift, a fix for the datetime conversion, and a possible fix for the thermostat heat/cool.

http://www.excaliburtech.net/downloads/HAILogger_1_0_1.zip

 

[pete_c]

Thank you rsw686.

Will leave the Omnistat2 in place tonight.

I will adjust the time sync to a longer interval just to see how off it is.

I will also do another warm reset for the time thing and try the heat/cool and auto heat/cool thing again.

 

[pete_c]

Installed and running. I am getting some odd heat and cooling set points. Checked thermostat and heat is 62 and cool is set at 82.

INFO: CoreServer: CONNECTION STATUS: Connecting
INFO: CoreServer: CONTROLLER IS: OmniPro II (3.11)
INFO: CoreServer: Retrieving named units
INFO: CoreServer: Unsolicited notifications enabled
VERBOSE: ThermostatTimer: Added to watch list Thermostat
VERBOSE: ThermostatTimer: Polling status received for Thermostat
VERBOSE: CoreServer: UNSOLICITED: ExtendedStatus
VERBOSE: ExtendedStatus: Auxillary 33 9 59 8 6 0 13 0 122 0 0 156 160
VERBOSE: CoreServer: UNSOLICITED: ExtendedStatus
VERBOSE: ThermostatTimer: Unsolicited status received for Thermostat
VERBOSE: CoreServer: UNSOLICITED: ExtendedStatus
VERBOSE: ExtendedStatus: Auxillary 33 9 59 8 6 0 13 0 120 0 0 61 96
VERBOSE: CoreServer: UNSOLICITED: ExtendedStatus
VERBOSE: ThermostatTimer: Unsolicited status received for Thermostat
VERBOSE: CoreServer: UNSOLICITED: ExtendedStatus
VERBOSE: ThermostatTimer: Unsolicited status received for Thermostat
WARN: TimeSyncTimer: Controller time 12/30/2012 22:26:46 out of sync by 14.15028
88 seconds
VERBOSE: TimeSyncTimer: Controller time has been successfully set
VERBOSE: ThermostatStatus: Thermostat, Status: 70 OFF, Heat: 113, Cool: 136, Mod
e: HEAT, Fan: ON, Hold: OFF
VERBOSE: CoreServer: UNSOLICITED: ExtendedStatus
VERBOSE: ExtendedStatus: Auxillary 33 9 59 8 6 0 13 0 121 0 0 108 160
VERBOSE: CoreServer: UNSOLICITED: ExtendedStatus
VERBOSE: ThermostatTimer: Unsolicited status received for Thermostat

 

[rsw686]

My mistake. I was using the SDK Text() function to get the readable values, which had a side effect of trying to insert INVALID into an integer field. I changed it to log the raw data and assumed it worked without looking at the actual data. It turns out the values are 0-255 with 0 being -40 C and 255 being 87.5 C. Increases are in .5 C and when converting to F it rounds to the nearest degree. I decided the best fix is to use the Text() function and try to parse to an integer to log into mySQL. It if can't parse the value it will log 0 instead failing trying to log INVALID.

Fixed version below
http://www.excalibur...ogger_1_0_2.zip

 

[pete_c]

Thank-you rsw686.

A quick look this morning shows:

WARN: TimeSyncTimer: Controller time 12/31/2012 06:43:56 out of sync by 124.1031968 seconds
WARN: TimeSyncTimer: Controller time 12/31/2012 06:43:56 out of sync by 124.2437984 seconds

I went though my automation lines to just look see if there was anything out of the ordinary and there wasn't. I have only added one or two lines of events in the last 4-5 months.

Just to see what happens this morning disabling the Omnistat2 physically removing the wires from the panel and removing it from PCA for a bit to watch the timing thing.

Leaving the ground wire in place and just disconnecting zone 16 (yellow) and green wire next to ground (powering off panel before removing wires).

 

[pete_c]

Disconnected power and battery. I removed the two aforementioned thermostat connections (yellow and green) and left ground wire in place. Checked thermostat and it is functioning fine.

I have one outside and one inside external temp/humidity sensors and left those in place.

I do not currently have the one external (plugged into the thermostat) temperature sensor hooked up.

Powered up panel. I then ran logger and time synced right away.

I then edited the Omnistat2 thermostat out of the panel via PCA. Saved configuration.

Now watching time on logger to see if it stays in sync or not.

I will let it run as it is for a bit then maybe in a few days reconnect the Omnistat RC-80.

I am still getting a 20 second average time sync off every 10 minutes now with the thermostat disconnected.

This maybe rules out that it was the thermostat causing the issue.

Initially when the issue came up I would disconnect the network interface and all would be well. A side note is that I have always had an NTP server connected to a GPS for internal time sync never really using the internet for time sync (blocking ports on firewall for said internal time sync functions)

I started to play with the PCA time offset; it was set to 30. I set it to zero and locked up PCA.

Trying it now at 34 just to see what happens.

 

[pete_c]

Oddest occurances.

Aside from testing with and without serially connected Omnistat; I removed every serial device; configured the panel with PCA not to include serial device; tested timing and it kept going off by about 20 seconds every few minutes.

The final test yesterday to today was reconfiguring the OPII panel with all of my serial devices to the way it was. I then did a time sync while connected via the network interface. Disconnected the network interface for periods of time up to 2-4 hours and then connecting network interface the time sync remained correct.

I don't understand as this is the only way that I could get my time sync back procedure. That said I would typically leave the network interface off for a few days; then reconnect it and all would be well until the next time the "issue" occurred. The very first time I saw the issue was when I first installed the Omnistat2; so I "blamed" the Omnistat. I removed the Omnistat from the panel and the timing issue remained. That said though I am still seeing a zero then a correct ambient temperature on all of the Omnitouch panels and PCA access as before. It seems more prevalent on the serially connected Omnitouch panels than the networked Omnitouch panels. I think the zero / actual temperature thing will settle after a period of time (historically it has).

Thank you for providing me with a tool to check the panel and time sync.

For now will leave the network connection off and see what happens after a period of time; most important to me right now is that the panel keeps time without having to adjust it every 10 minutes.

 

[pete_c]

Just noticed after XX hours of no network connection that all of the serially connected Omnitouch screens are showing the actually ambient thermostat temperature and not flickering back to zero at all. That and the time "minute" matches my PC time.

 

[rsw686]

Out of curiosity is the controller ground connected? I'm using an Elk transformer which has a ground terminal so it was simple to hookup.

 

[pete_c]

Looking (cuz its been so long I may have forgotten).

Power source for HAI OPII

HAI transformer is inside of the Leviton panel power supply on bottom of the can, it is the simple three AC "pronged" with two AC terminal on it (no grounds on either side) going to = = > 12 guage 24VAC 2-wires going next "door" to the HAI OPII can (36" maybe?).

I do have an Elk power supply for the supplimental HAI furnace thermostat power and it does have a ground wire terminal (but it is not connected) and it is hanging off of the furnace switch. It is three pronged on AC side with the extra ground terminal on the LV side.

Would you recommend switching the HAI 24VAC transformer providing power to the panel to the Elk 24VAC transformer and connecting the ground terminal on the Elk transformer to same earth ground? (this is relatively easy to do).

Or just purchasing a second Elk 24VAC transformer replacing the HAI 24VAC transformer (they look identical except for the LV ground terminal between the two 24VAC terminals)

The OPII panel ground terminal is using a (looks like) 10 guage aluminum wire to the ground post on the OPII board (1st one on the left).

This wire connected to a ground "strap" on an electrical conduit about 36 inches below the OPII panel.

I can switch this over to 10 guage (or less) copper and shift the clamp over to the fuse panel ground conduit (with a bare copper strap inside of a 3/4" conduit over to the water supply pipe and the ground stake outside of fuse panel (electric service entrance).

Connecting the HSTouch hub / Video Hub about 25 feet away recently and I did connect three wires for the touchscreens as specfied (ground, A and B using 22 guage 4 wire alarm wire). Should I also add another ground wire to a clamped to conduit earth ground with this can and panel? I have switched over all of the legacy HAI Omnitouch consoles and keypads over to this HAI panel. (put an oversized back up battery in the can too). It is powered by standard HAI specified AC to DC transformer. Now I am wondering if I should replace it with something better? It is just using the two wire DC barrel connection over to the Omnitouch Hub / Video hub panel. The "issue" though did exist well before I installed the Omnitouch hub / video hub stuff though.

So proposing here (maybe a fix for my issue?).

BTW are you using the ground terminal from the Elk transformer to the HAI OPII panel ground terminal or did you just connect the Elk ground terminal to an earth ground and use a separate ground wire to ground for the HAI OPII panel?

1 - Switch the HAI 24VAC transformer with the Elk 24VAC transformer.
2 - Connect the ground terminal on the Elk 24VAC tranformer to a ground strap (just using the electrical conduit next to the Leviton panel).
3 - change the 10 guage aluminum ground wire to ground strap over to 10 guage copper wire and to a different ground strap connected to the conduit which hold the braided water pipe ground going to the fuse panel from the water pipe.

 

[rsw686]

I don't know if the grounding will make any difference with your time issue. HAI states to connect the controller ground to a water pipe or grounding rod. I connected the controller ground to the Elk transformer ground. My logic was the outlet ground should have less resistance than connecting to a water pipe. Since the serial ports have a ground pin I could see issues arising if the controller was at a different ground potential. Interestingly Elk states to not connect the ground to their M1 controller.

 

[pete_c]

Thank you rsw686.

I am now at over 12 hours without the network cable connected. Time is still in sync within a minute from what I can see.

The serially connected Omnitouch screens / thermostat display is now continously showing the thermostat ambient temperature.

Typically I would leave it like this for a few days then plug the network cable and I would be fine until the next time.

While there is no apparent rhyme or reason for the issue; it appears to be triggered when the thermostat is switching over from no heat to heat or from no air conditioning to air conditioning use. That said I never saw this issue with the Omnistat RC-80 thermostat connected. (for years).

I did start on installing a new ground into the Leviton panel today running a short 12 guage stranded cable from the currently utilized for the OmniProII ground strap to the location of the HAI 24VAC power supply. Tomorrow will swap the Elk power supply with the HAI power supply and just see what happens. I don't think it'll be an issue doing this.

Concurrently will connect a serial port for HAI serial access to the serial to network device I have around (Quatech box).

Do you have the option of utilizing your HAI logging application via a serial connection?

 

[pete_c]

This morning I switched the HAI 24VAC power supply with the Elk 24VAC power supply with ground and connected ground.

I also set up another serial Omnitouch such that it is adjacent to the HAI panel. Did a quick test plugging in the network cable.

When I plugged in the network cable the temperature on the Omnitouch thermostat setting went from ambient temperature to zero continuously.

For the time being I unplugged the network cable.

 

[pete_c]

Thank you rsw686 for helping me and providing the diagnostic logging program

Connected the network cable this afternoon and thermostat status stayed at the ambient temperature.

Checking the time with the data logger and it has remained in sync.

The HAI network cable has been in place now for about 10 years or so. That said I had previously tested a new patch cable to a new switch and continued to have the problem.

Decided to fish a new cat5e patch cable to the HAI box; plugged it in to the same switch as earlier utilized.

Maybe the old HAI network cable had degraded (contacts looked clean though) causing an intermittent problem?

I don't know though why this would cause the comm issue with the Omnitouch or the time off sync issue.

I am working fine now and can reconnect my Omnitouch 5.7e's.

BTW are you doing anything with your data logger or similiar in Linux?

I've been playing with what appears to be a "do all" linux based touchscreen apparently given out to utility companies to test zigbee. It has a DECT VOIP set up along with a blue tooth interface, wireless and a Gb network connection. I have a few of the same type motherboard / touchscreen setups and currently have just replaced the firmware on them such that I could play some more with them.

 

[rsw686]

The HAI SDK does have serial support, but I didn't build support into the logger. The issue is serial uses OmniLink and TCP/IP is OmniLink II. For every function you have to do if version 1 do this else version 2 do this. I was after TCP/IP so I left out the complexity.

As far as linux support the HAI SDK is a C# library. I don't know if the compiled library would run with Mono C# on linux. I do have a number of CentOS VMs (LAMP, Zimbra, Asterisk, and DHCP/DNS server) and originally wanted to write the logger to run on linux. However when I found the HAI SDK I went that route to save days of development time reading the OmniLink II documentation and implementing the low level commands. With the HAI SDK I had the logger up and running in a few hours.