[BUG]: changing sensor alarm values doesn't respect day/night offset?

[rossisbudda]

Setup:

• TerrariumPI version: 4.12.5
• Install: Manual
• Raspberry PI: 3B
• OS: Bullseye

Describe the bug
Apologies in advance if I have got the expected behaviour incorrect.
I have noticed that when I make changes to the sensor alarm values during the night period, that the day period then becomes offset by an extra amount. It's as though the day/night offset values do not get considered while editing sensor alarm values.

To Reproduce / Installation steps
Wait until night period. Change the sensor alarm values. Wait until day period. Notice that sensor alarm values have shifted by an amount that is beyond the day/night offset value. It is as though the only safe time to enter your favoured value is during the day.

Expected behavior
I would expect the day/night offset value to be understood relative to our current day/night period when editing sensor values, then for the alarm values to behave predictably when we return to the next period.

I am really sorry but I can't get to the logs right now.

[theyosh]

If you use day/night difference in your area, you cannot change those sensors in the same area during the night. That is just not possible.

so this is the correct behavior.

I will update the documentation to make this clear. I see that it is currently missing.

[rossisbudda]

Thanks.

I guess it makes sense as the sensor is somewhat independent of the enclosures.
It's slightly inconvenient as I often need to interfere for some tweaks, mostly during night period.
However I suppose I can set the sensor for a daytime alarm and work with the day/night offset per area instead?

Thinking out loud, perhaps it would be useful if we somehow had the ability to enter per area values that are absolute rather than relative, to truly decouple sensor from area, and day from night...?

[rossisbudda]

Probably because the alarm per sensor logic predates the enclosures.

[theyosh]

I am still working on a fix :)

I need some time to test this....

[theyosh]

I have looked into the code, but I do not see any issues regarding changing sensor settings during the night. I think it was a problem in the past, but should not be a problem anymore.

I have changed some sensor values during the night, but the day/night difference was processed correctly.

So I was wondering if this what you have seen happens often, or was it just a one time thing?
The only thing I can think of is that the software had a restart around 00:00. Because that could cause it, but not sure about it.

So you should just be able to adjust your sensors during the night period. That should just work.

I can't explain it right now why this has happened.

[theyosh]

Ok, I have tried all kind of updates to a sensor that is used in an area with day/night difference and I cannot reproduce your issue.

As it is possible to change the sensor value any time of the day, my first remark of not changing during the night is not valid.

So I cannot explain why you had this issue.

Is it still happening when you change the sensor alarm values?

[theyosh]

Closing this issue as it looks a one time issue.
After a week testing by changing sensor values during night time on an area with day/night difference works like expected.

I could not replicate the issue. If it still exists, you can re-open this. But please do provide some more information on what happened.

[rossisbudda]

Thanks, yes I’m sorry. I’ve been too busy to give a proper detailed response or make any extended tests of my own. I did notice some other possible confusing behaviour when using heating and cooling offsets in combination with one another but for now I have to leave my system to run, and once it is not in action I could consider making more tests without upsetting the operation I have. Thanks for your help as usual.

…

On Fri, 10 Oct 2025 at 18:19, TheYOSH ***@***.***> wrote: Closed #1028 <#1028> as completed. — Reply to this email directly, view it on GitHub <#1028 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMD3C2QMO5LGIXWUU2WARVD3W7TCRAVCNFSM6AAAAACHLQ2CKCVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMRQGIYTGMZRGE2DQOI> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[rossisbudda]

TerrariumPI version: 4.12.5
Install: Manual
Raspberry PI: 3B
OS: Bullseye

Hello. I'm back 😈

Think I can begin to explain the second part of the issues I first came with way above. You'll see the same effect in my first screengrabs if you compare later.

Describe the bug
This time I was able to make another unusual behaviour when working with day/night. Please bare with me as I attempt to explain the steps etc. I anticipated an issue so was able to catch the feedback.
my observation is one related to a bug that seems to apply a negative offset where i have postive defined? or that day and night are not considered exclusively, and day/night diff really refers to current/next diff?

Right now I aim for temp 28.5 during day, 25 during night.
Had to manually override for 48 hours of night, so just set manual mode on lights and forced temp to my 25 in the sensor alarm value. Now I needed to undo this so used the opportunity to test.

To Reproduce / Installation steps

• its night period - temp sensor alarm value is set to 25.
• day will come - i want to be at 28.5 then, so i set day/night diff to +3.5 in enclosure area, sensor alarm stays at 25.
• day comes - alarm value plummets to 21.5! this is wrong?!
  
  
• its now day - having caught this, I reset the day/night diff to 0, to maybe reset the alarm at 28.5? - sensor alarm stays at 21.5!
• so i force the sensor alarm value to 28.5
• now i set the heating offset to -3.5, sensor alarm stays at 28.5, everthing will continue fine.

Expected behavior
Slightly confused but wanted to flag this as I think the concept of a single sensor alarm value is outdated by areas and enclousures, and makes more sense to me that the alarm value for day and night could be setup per area instead. I've made enough mistakes to say this is either buggy or unititive, or both.