Initializing values on boot

[J V]

Hello,

Strange question perhaps... Do you guys take care to properly initialize values when your miniserver boots up and let it wait? Let me explain.

A simple example is a radio button to set the input of my amplifier: AIs on the Radio Button takes the current source of the amplifier (from a virtual input), the different Qi's trigger different sources (to a virtual output). The AIs only gets a signal when the amplifier changes source or is queried, so when the miniserver reboots, it does not get a signal of the current amplifier input, and just sets the first input and sends this to the amplifier, causing it to change. I know I can set "remanence" to make it remember the last setting on the radio button, which would be wrong if the amplifier changes in the mean time (but we can assume that if the miniserver is down for long enough for me to change the amplifier, there will be bigger issues ). So this is solvable.

A more complicated example, where I'm unable to do this is with my thermostats: I have both an operation mode (home/night/away, each of which has its own default temperature) and a setpoint shift (to deviate from the default temperature). For some reason, when the miniserver boots, my setpoint shifts are all over the place. I suspect the cause is in the incorrect order of initialization which triggers the miniserver to change the setting of the thermostat. I'm not sure my problem is related to the startup initialization order of different variables, but I have no other idea what it could be so for now I'm just forcing the miniserver to set default values, 10s after boot, to just have a reasonable fallback (e.g. not to have room temperatures suddenly at 30°) in the event the miniserver reboots.

To make it possible for the miniserver to first learn the situation (e.g. in my case: thermostat operation mode, setpoint shift), it would require quite some elaborate logic just to make sure the miniserver first queries everything but at the same time waits with applying its logic and prevent it from changing settings until it has read all relevant data. At the moment, I don't see the point of doing so in normal situation if default values suffice (I noticed the issue as now I'm changing a lot in the config and testing, so my miniserver often loads a new config).

How do you guys do it?
My miniserver is not on a UPS, so a powerfailure could trigger a reboot which could yield uncomfortable settings.
Is there an easy way, or you also just revert to default values?

Thanks!

[Tico]

This appears to be a significant short-coming in the Loxone logic. I'm surprised Loxone hasn't addressed the issue because it must be a common problem across most users.

I have addressed the retention of analogue values across reboots in the attached logic.

I have an Uninterruptible Power Supply that sends 'minutes remaining' of UPS power. When this value gets to a certain threshold, various services have a controlled shutdown. Without the work-around, a reboot would cause significant disruption when the 'minutes remaining' briefly dropped to zero.

[Giovani]

I experience simmilar issue - even when I download configuration (new program) to Miniserver and it "reboots" after loading new program it is happening that durring reboot some values are changed to 0 during reboot and then comes to normal value after program is loaded. This happens also to output of AnalogMemory functional block eventhough I enable remanence on it.

As I remember this was not a case before, I detected this yesterday. Still investigating.

I also experience that downloading and loading program takes longer time (my MS is on FW 10.3.11.25 with calculated 38% utilisation)

[J V]

Tico: It would be nice if there would be some "pulse on initilization", which would tell the miniserver its logic can start to work. I don't have my miniserver with a UPS, but luckily unscheduled power failures are very uncommon. Just now when trying things it is more annoying. On a next renovation I will probably get some things changed to my electricity as well and then the miniserver may get a UPS. But nothing urgent.

Giovani: I also have the impression that it got worse... Some things I have not changed, and I don't recall having my setpoint temperature jump to 30 degrees on loading a program. I also noticed that remanence does not always seem to work immediately.

So it seems the solution to just set some "safe, general" defaults is the simplest way to go now.

[Tico]

J V -

Is it possible to adapt the logic above to the Setpoint shift? Without seeing the logic, it's difficult to anticipate where the reboot is causing the problem. It might even be enough to use a simple Memory Flag with a delay of 100 cycles for some critical values. You would need to experiment.

Overall, I think the PLC processing needs to be delayed by half-a-second until all inputs are initialised. It's very close, which leads me to speculate that this has just gone 'out-of-spec' with various new Config versions.

[J V]

I have tried various things, and honestly have no idea why things such as remanence do not work. The easiest would be to just enable that for the setpoint shift and upon reboot it should be fine, or at least close enough not to cause much issues. But even when the shift is 0 on the room thermostat, 0 in Loxone and remanence in the block is enabled, then still for some rooms it sometimes (!!) jumps to the max value of the plus/minus switch.

I now suspect it has to do with the processing I need to do to interpret the knx value (I'm not home and cannot see the config now), but the knx thermostat returns a type that the miniserver can only interpret as a percentage. So I need to scale (if I remember well: 0 to 49 -> 0 to 12.5 and 100 to 55 -> -0.1 to -12.5; writing this makes me suspect this is where it goes wrong... when it reboots... But it did not use to go wrong a few years ago...

I've also tried saving the values using an analog memory and a pulse on startup, but as I don't know if this happens before all else it did not change the behaviour. For now I'm just setting safe values 5s after the miniserver boots. At worst the temperature setting is a bit off until the next scheduled change, but at least it won't heat up to 30 degrees.

[Giovani]

some update from investigation:
what I see for now is that during reboot/restart (after new software download) for short time all virtual inputs goes to 0 (zero) and also all 1wire temperature values goes to 0.
Eventhough it is a kind of reboot to load new software global system variable *Seconds since boot* stays untouched during such reboot/restart.

[Giovani]

Tico J V is anybody of you already running Loxconfig version 11 to check if same behaviour is also on latest version.

[Tico]

Not yet. May give it a try in the weeks ahead.

[J V]

I'm running 11, but it is not better than in 10... I haven't seen the behaviour you describe, but am not sure how to look for it (it takes a while for liveview to show). And my values are not from virtual inputs...