WTF is going on with my PTC sensor?

[xsherlock]

ok that sensor is sighting in unheated room on my  with max temp of 6 deg C.

I hace second one next to it 5cm away that is fine.

 

Results read with openhab and with brickv and they are the same.

 

Maciej

[borg]

Perhaps the sensor is not screwed into the terminal tightly enough and there is a loose connection?

[bixator]

I have exactly the same issue with at least 2 PTC bricklets.

One is connected 'remotely' using RS485 extensions but the

other one is local.

The issue can last for several hours (!) and I didn' find any other

workaround than resetting the Master brick the PTC bricklet is

connected to.

Sometimes, the PTC bricklet recovers by itself.

I've checked the phyiscal connections and they look good to me.

The is_sensor_connected() returns true anyway when this issue happens.

 

Is there anything else to check ?

Thanks.

Regards

[borg]

So the wrong values disappear immediately if you restart the Master Brick? That is very strange, it implies that there is some kind of "bad state" that is lost after a restart of the Master Brick.

 

Do you have to disconnect the power or is it enough to press the reset button?

 

 

[xsherlock]

I did review my install and swapped the cables on the offending sensor.

Does it makes any difference if the red is B and C is white? It shouldn't I think.

Instantly the sensor went to normal temp and is staying there for now.

[bixator]

Hi,

 

So the wrong values disappear immediately if you restart the Master Brick? That is very strange, it implies that there is some kind of "bad state" that is lost after a restart of the Master Brick.

 

Do you have to disconnect the power or is it enough to press the reset button?

 

 

 

I don't disconnect the power, I perform the reset of the of the master brick

in the stack the faulty PTC is attached to, using the brick viewer application.

Please note that when this issue happens, the brick viewer reports the

sames temperature value for ages, which in my case does not make sense at all.

 

So, I was considering monitoring the temperature value changes over the time

in my application and perform an "automatic reset" of the master brick

but this sounds overkill to me...

Any advise would be welcome.

Thanks for your help.

Regards.

 

[xsherlock]

After swapping cables around my PTC sensor surprisingly got OK and gets me reasonable values for the last week.

 

You can not rely on the is_sensor_connected because in my case it was also showing that the sensor is connected when the readouts were bogus.

[borg]

Good to know that it works now. As long as the resistance from the PTC sensor is in a "possible range" it can't tell that it isn't connected correctly. I think that was probably the problem here .

[bixator]

Good to know that it works now. As long as the resistance from the PTC sensor is in a "possible range" it can't tell that it isn't connected correctly. I think that was probably the problem here .

So, I guess that my issue is probably different then.

As you can see in the attached screenshot, I got the issue

from 2 different PTCs (temperature value is flat for a while).

Regards.

[borg]

So, I guess that my issue is probably different then.

As you can see in the attached screenshot, I got the issue

from 2 different PTCs (temperature value is flat for a while).

Regards.

Indeed, that looks different. Does the flat value recover after a while or do you definitely have to reset?

 

I just looked through the code, if "is_sensor_connected()" returns true during the flat time, it means that the MAX31865 IC that we use on the PTC Bricklet does return the same resistance for the whole time.

 

If you reset the Master Brick, the MAX31865 will be reinitialized. But during initialization we only configure the default values again.

 

For testing, could you try to call "set_noise_rejection_filter" (it does not matter if you turn it on or off). Internally this will also set the whole configuration again. Does this also fix the problem?

 

If it does fix the problem, we may have to set the configuration periodically in the firmware? Sounds strange, but i currently have no other idea .

[bixator]

I just looked through the code, if "is_sensor_connected()" returns true during the flat time, it means that the MAX31865 IC that we use on the PTC Bricklet does return the same resistance for the whole time.

 

If you reset the Master Brick, the MAX31865 will be reinitialized. But during initialization we only configure the default values again.

 

For testing, could you try to call "set_noise_rejection_filter" (it does not matter if you turn it on or off). Internally this will also set the whole configuration again. Does this also fix the problem?

 

If it does fix the problem, we may have to set the configuration periodically in the firmware? Sounds strange, but i currently have no other idea .

Thanks for the tip, I will give it a try. Currently, I poll the PTC every 60 seconds using a small Python script based on your API examples.

I'm planning to store the values and monitor for unchanged value for a given amount of time, and then try to call the set_noise_rejection_filter() function if the value remains the same.

The issue is to be able to detect if an unchanged value is valid or not.

Regards.

[bixator]

Hi,

 

Just did a quick check today and found this surprising issue.

There is currently no PTC probe connected to this PTC bricklet

but the Brickd and/or Brick viewer (cf attached screenshot) don't agree...

Any idea ?

Regards.

[borg]

So it seems the MAX31865 for some reason doesn't change its state anymore after a while?

 

I would say we ship you a new PTC Bricklet, but you have this exact problem with two PTC Bricklets, right?

[bixator]

So it seems the MAX31865 for some reason doesn't change its state anymore after a while?

 

I would say we ship you a new PTC Bricklet, but you have this exact problem with two PTC Bricklets, right?

Indeed, I have 4 PTC bricklets with PTC connected to them and 2 other bricklets

in the stack but without any sensor connected yet.

Two of them seem to have this strange behavior very often, the 2 other get it from time to time only.

BTW, I've tried to use the set_noise_rejection_filter() call but that did

not help that much so far.

Thanks for your help.

Regards.

[xsherlock]

One more thing I noticed with PTC and normal sensors is that they are sensitive to the fact if 230V power cable is any nearby. Sometimes this introduces a jitter in the readout. I would keep at least 10 cm space

[bixator]

Hi,

 

Still fighting with these PTC issues, I'm tracking the values and try to check for suspicious values.

I've been able to detect this morning that 2 of the 4 PTC connected to the same master brick we reporting constant and invalid values.

Reseting the master brick did clear the issue but this mechanism is not really reliable.

Regards.

[xsherlock]

Just today I got some bogus values, not absurd like previously, but for sure false.

 

The 3 PTC probes are inside the 1.2m3 of hot water tank that did not cool down magically by 6degrees for half an hour.

 

------

Ohh, that was easy, when I switch light in the basement and get this result, so that is noise from AC wire I guess.

[tfRookie]

Hi,

 

I just wanted to raise this subject again ... especially as I had reported the same 6 degree drop as the last poster 1.5 years ago in the German part of the forum (http://www.tinkerunity.org/forum/index.php/topic,2810.msg17826.html).

 

Even if it might be triggered by AC installations around (difficult to avoid them), is there already a known solution (Tinkerforge?) for that issue?

 

I would really appreciate your feedback as this is getting a more and more critical issue for me.

 

Thanks!

[mniehren]

Hi,

 

i have the same problem here. After setting 1 digital out

in the industrial quad relay to true and after that to false again, the PTC works correct again.

 

best regards

  Michael

 

[tfRookie]

Hi Michael,

 

After setting 1 digital out

in the industrial quad relay to true and after that to false again, the PTC works correct again.

 

you are referring to a bricklet other than the PtC here, right?