Suggestion/request for WC32 temperature sensors

[rossw]

With the extra processing power and memory of the WC32, what's the chance that we can have it expanded to handle more than 16 temperature sensors? Since they're all on the bus, there's no hardware change to do it, just code.
 
I've got an application that would consolidate three WC8 boards into one WC32, but I need at least 20 temp sensors to pull it off.
If we could go to 24 would be great... or (since we have a "lock" mode ("Temp Sensor Config") - perhaps we could simply connect as many sensors as required and enable the board to scan them??
 

 

[CAI_Support]

Hi Ross,
Yes, that is possible. It will slow down the sensor updating frequency, since one bus to read that many sensors in series.   For application does not care about fast temperature change, that is okay. Currently, temp sensor is updated every second, worst scenario is under two seconds, to capture any temperature change. With 24 sensors, it will be like four seconds update time.

 

[LarrylLix]

My house stats via a RPi (NodeLink) to my HA only updates every 45 seconds.
Temperatures don't change that fast.

A user settable scan time may be appropriate, also. Every 15 seconds would be just fine for any application I can think of. The sensors don't respond that fast anyway.

 

[CAI_Support]

DS18B20 could respond faster, if extending its ground pin to the heat source, since it is sensing temp change through its ground pin. 
It is hard to make scan time user configurable, since that will have to change task scheduler.  However, if most people does care about the temp sensor update frequency that much, we will change it to allow more temp sensors on WC32

 

[rossw]

All sounds great to me.
While response time is of "some" concern to me, if we're still talking sub-10-seconds I don't expect it to be any issue at all!

 

[LarrylLix]

Make it adjustable.
eg:
Every 10 seconds handle up to X sensors
Every 3 seconds handle up to X sensors.

 

[CAI_Support]

For how many sensors the firmware can handle, it must statically allocate memory, all its GUI must also change, web interface and backend communication all have to change. There is no easy way to configure it not affecting the remaining logic.

 

[rossw]

Perhaps, just make a note about the time it takes to scan a sensor and let the user optimise their design based on their need for speed of response, or number of sensors?
I know the time does depend a bit on the value being returned, but lets say it's a "worst case" of 175ms per sensor, let the scheduler just read the first, then the second, then the next etc until all are done, the start again.
8 sensors could take 1.4 seconds.
16 could take 2.8
24 could take 4.2
If we know the worst-case-time-per-sensor we can design around it.
Means no "knobs to twiddle", everyone wins, yes?
 
Since the process runs in the background (to the user code), it's just like they would refresh as if by magic, we don't actually need to *DO* anything, except know how often the data is likely to change, so we can optomise loop timings, feedback constants etc.

 

[CAI_Support]

One thing we need to make it clear that after adding more temp sensors, all PLC code must be saved from board and reload up to the board, since added temp sensors will change some data ID sequences, if not reload PLC code after firmware update, it will NOT work properly.

 

[rossw]

One thing we need to make it clear that after adding more temp sensors, all PLC code must be saved from board and reload up to the board, since added temp sensors will change some data ID sequences, if not reload PLC code after firmware update, it will NOT work properly.

 
Really looking forward to testing this new code
 
Question however: *IF* you're coding this so that it will do entirely dynamic pool assignments.... what will happen in the scenario where a sensor fails and the board is subsequently rebooted? If the failed sensor is (say) #1, will all the others "move up" one? This could be disasterous!
 
Or, once it's "learned" the sensors it has (and presumably stores their ROM codes in EEPROM/FLASH, will it always allocate the right amount of memory, so pointers will always be right, even if a sensor is removed/unplugged/failed?

 

[CAI_Support]

Ross,
 
In our current firmware (last release in 2016), it already has a checkbox in setup screen to either scan the temp sensor bus or not during boot up. If configure temp sensor box is not checked, it will not scan the bus during power up, rather, it reads from the EEPROM from your previous assignment. 
 
If any of your board does not have that checkbox in setup screen, you may consider update firmware to get that feature.  That is an important update.

 

[Efried]

My house stats via a RPi (NodeLink) to my HA only updates every 45 seconds.
Temperatures don't change that fast.

A user settable scan time may be appropriate, also. Every 15 seconds would be just fine for any application I can think of. The sensors don't respond that fast anyway.

 What is the availibility /uptime of the RPi solution compared to the WC? 

 

[LarrylLix]

Very good from my ISY to the RPi but the Venstar thermostats have very poor healing powers if the router goes down.
 
This happens when I play with settings on the router, or we get a hydro grid blink with the frequent windstorms here.
 
 
The RPi has been more dependable than my WC8. I didn't have to build in any compensation for rebooting. MInd you, that seems to be mostly solved now, after my first year of trouble with it's bad 1wire system.
 
My Rpi also runs a few other multitasking systems to service my ISY994 HA, and as well, it can act as a full PC system, simultaneously. I have since purchased another multicore RPi 3 for that purpose, for fear of breaking my serious system jobs.

 

[CAI_Support]

Beta test firmware sends to Ross for testing. Once tested okay, it will be released.
The more temp sensors, the longer time for all sensors updated. It always running at fastest possible time, so there is no need to be configured.