Originally posted by G4RHL
View Post
Evohome Hot water problems
Collapse
X
-
Originally posted by mtmcgavock View PostHave you ever considered it could be the physical sensor that’s causing the issue (the bit that straps to the tank) resistance dropping out causing the CS92A not to behave
My system I use the probe, whereas yours I’m assuming you use the strap on sensor being a gravity fed system.
When I moved the CS92A back to its old location yesterday I had to disconnect and reconnect the wires to the rear plate so they have been re-terminated in the process, (and the previous connection of the wires into the terminal blocks was good) but problems persist.
While it's a theoretical possibility I don't think the sensor or sensor connection is the problem, unless the faulty connection is one of the pins that goes between the terminal block on the back plate and the front half where the PCB is. That is certainly a possibility, and would tie in with the poor connection theory. I have not deliberately disconnected the sensor to see how the system reacts - but I will when I do some testing soon.
I plan to take apart the CS92 and carefully inspect all the contacts - both battery contacts on the rear of the PCB and the pins that connect front and rear halves together, however I'm waiting for my NanoCUL to arrive first to try to do some wireless traffic capture while the sensor is misbehaving just in case tweaking the contacts seems to fix the issue. That way I have some before and after captures, and I can see exactly what the sensor does or does not send when the sensor is disconnected or when it doesn't seem to be updating.
Comment
-
-
maybe a question to ask and get feedback on, is how many are using the Strap On sensor and having issues. I am using the insertion sensor and it's been fine. I used to get the occasional comms lost message but even that hasn't occurred for a while. another theory, I use Domoticz which I know is constantly polling the controller for DHW state and temperature. Could that in some way be forcing the CS92A to stay in touch better than normal?
Comment
-
-
It could be the temperature sensor/probe itself i.e. the temp sensor that connects by wire to the CS92A? My probe was reading 66 degrees C 4 months after a new install.
There has been no further rogue readings since it was replaced.
Comment
-
-
Originally posted by bruce_miranda View Postmaybe a question to ask and get feedback on, is how many are using the Strap On sensor and having issues. I am using the insertion sensor and it's been fine. I used to get the occasional comms lost message but even that hasn't occurred for a while. another theory, I use Domoticz which I know is constantly polling the controller for DHW state and temperature. Could that in some way be forcing the CS92A to stay in touch better than normal?
Also when I received my replacment CS92A from Honeywell, I also changed the sensor just in case.
I'm also on 55 degrees/10 degree differential at the moment, though have tried various values in trying to find a solution.
Comment
-
-
There's something odd about the CS92A and particularly the comms side and the way it interacts with the controller because several times now people have reported here suddenly getting errors on multiple (radiator) zones as a result of low battery in the CS92A.
If that had happened once I might consider it to be fluke or user error but I can think of at least three reports, possibly more.
The CS92A shouldn't affect radiator comms at all, but it does.
It does, however, suggest that the problem might lie in the controller rather than the CS92A itself. Or perhaps a bit of both.
Comment
-
-
Originally posted by paulockenden View PostThere's something odd about the CS92A and particularly the comms side and the way it interacts with the controller because several times now people have reported here suddenly getting errors on multiple (radiator) zones as a result of low battery in the CS92A.
If that had happened once I might consider it to be fluke or user error but I can think of at least three reports, possibly more.
The CS92A shouldn't affect radiator comms at all, but it does.
It does, however, suggest that the problem might lie in the controller rather than the CS92A itself. Or perhaps a bit of both.
Comment
-
-
Originally posted by paulockenden View PostThere's something odd about the CS92A and particularly the comms side and the way it interacts with the controller because several times now people have reported here suddenly getting errors on multiple (radiator) zones as a result of low battery in the CS92A.
If that had happened once I might consider it to be fluke or user error but I can think of at least three reports, possibly more.
The CS92A shouldn't affect radiator comms at all, but it does.
It does, however, suggest that the problem might lie in the controller rather than the CS92A itself. Or perhaps a bit of both.
We know that when the CS92A powers on / boots up it immediately sends a temperature reading. We also know that the spec for comms on this frequency range state that each device must transmit with a very low duty cycle - less than 1% of air time from memory - to keep collisions at a minimum.
As part of that it's required that each device keep track of how much air time it has used recently (in the last minute ?) and refuse to send any further packets if it has exceeded its allocation for that time period, and not transmit again until the next time period - we know the HGI80 does this for example - if you send it too many commands in too short a time period it will refuse to send some over the air to adhere to the limits.
However imagine that the battery voltage is teetering around a threshold where the device shuts down and powers on again - every time it powers on it probably forgets how often it has sent recently, sends a temperature broadcast, as part of sending that broadcast the power drain on the low voltage high resistance cells drops the voltage below the threshold and it shuts down again. When it shuts down the voltage rises again and it boots up again. Repeat ad nauseam and you are suddenly sending a continuous storm of broadcast messages without regard to air time limits. This would absolutely cause problems with all other Evohome devices at the property and is essentially a form of denial of service "attack".
If this is really what happens it would be easy to prove it with something that could monitor the over the air messages. Just a theory, but it's at least plausible. It could be something as simple as insufficient hysteresis in the power management / reset control of the SoC which decides at what voltage the device shuts down or boots up. If the hysteresis is too small in relation to the impedance of the depleted batteries and the load drawn by the transmitter it would cause an oscillation that resulted in continuous reboots.Last edited by DBMandrake; 31 January 2020, 06:01 PM.
Comment
-
-
And another 3+ hour outage of the hot water sensor tonight resulting in an error on the screen and no hot water reheat. Take the battery out and put it back in - instant temperature reading. Getting a bit boring....
Trying to resist the urge to rip the CS92A apart before my NanoCUL arrives..Last edited by DBMandrake; 1 February 2020, 07:22 PM.
Comment
-
-
Originally posted by paulockenden View PostProbably a silly/annoying question but have you tried another battery?
If anything it made things worse, although I suspect the physical disturbance of the battery contacts is the reason, not because there's anything wrong with the new batteries. (which there isn't)Last edited by DBMandrake; 1 February 2020, 11:56 PM.
Comment
-
-
Originally posted by bruce_miranda View PostI know, you shouldn't need to do this, but, do you want to try soldering a double battery holder directly to the PCB and see if that helps.
But first I'd like to try to capture some over the air traffic while it's misbehaving, so I don't want to touch it any further until I can do that. It seems to be playing up semi-regularly at the moment (even when I don't get an overt fault warning, I see from my graphs that almost every day updates are erratic and sometimes very delayed) so that seems like a good time to do some traffic sniffing and gather some hard data.
I have a spare Raspberry Pi 2 which I could set up as a dedicated 24/7 monitor with the NanoCUL, that would allow me to correlate logs from that with my temperature graphs and fault log... the only question is where to position it in the house. It's currently in the TV cabinet which is not a good place to ensure good reception as there is too much interference and too many other wireless devices near it.
However if I put it elsewhere the Pi itself would need to be on wireless, and the close proximity of its wireless transmitter might interfere with reception, so still trying to decide how and where it set it up.Last edited by DBMandrake; 2 February 2020, 10:18 AM.
Comment
-
Comment