Is anyone else finding Loxone really buggy these days?

[Simon Still]

This is a really straightforward bit of config that's worked for years, that's stopped working.

To open my blinds I've got two alarm clocks, one is set to 715, one to 1215

Theres a radio button block in the user interface that switches between them by disabling one of the timers.  I've tried various things in the last week (DisA's to both blocks, reversed DisA's) and this is simplistic just a simple the DisA is NOT disabling the alarms. 

[Simon Still]

I"ve rebuilt it all and made it all visible in the UI.  It definitely *looks* like the 715 alarm is disabled.  But the blinds are opening. 

Will see what happens tomorrow. 

[Jonathan Dixon]

Completely unrelated to your overarching question of bugginess, this is not how I'd use Alarm Clock blocks.

In the UI you can have different alarm times based on Operating Mode, so I'd have a single Alaarm Clock and use operating modes to setup the differing times, either weekday vs weekend vs holiday, or have a new dedicated Operating Mode called "lazy morning" and have the radio button active that, or whatever 

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/loxone-english/2dc7bf61-6701-41d7-b71a-0aeedb5b1948n%40googlegroups.com.

[Simon Still]

I’m using it for sun shading rather than the automatic shading block. It’s the living room and their vertical blinds pivoting. 

It’s an easy interface to shade for the morning when we have a run of sunny days. (The alarms themselves don’t normally appear in the UI, just the switch to change between two times. 

Sent from my iPhone

On 22 Apr 2026, at 10:50, Jonathan Dixon <jo...@lifelogic.uk> wrote:



Completely unrelated to your overarching question of bugginess, this is not how I'd use Alarm Clock blocks.

In the UI you can have different alarm times based on Operating Mode, so I'd have a single Alaarm Clock and use operating modes to setup the differing times, either weekday vs weekend vs holiday, or have a new dedicated Operating Mode called "lazy morning" and have the radio button active that, or whatever 

On Wed, 22 Apr 2026, 09:36 Simon Still, <simon...@gmail.com> wrote:

I"ve rebuilt it all and made it all visible in the UI.  It definitely *looks* like the 715 alarm is disabled.  But the blinds are opening. 

Will see what happens tomorrow. 

<IMG_1414.jpeg>

[Tarun Nagpal]

I use a schedule block for this in one place and have it pass a 50 value to the position pin when i want partial shading in the afternoon and would probably use two modes for switching between them on a schedule basis if i needed your type of functionality

Although realistically I would probably want a brightness sensor in a room like yours where it might be bright, it might not be.

Basically a schedule block passes the value and then uses an analog memory... The 2 hour monoflop basically says if someone adjusted the shades on their own, then don't do anything automatic for 2 hours. Intent should supercede automation.

I think you could do something very similar to override the schedule with a radio button to the monoflop or whatever interface you like, then you just name it "skip morning shade" or whatever. But honestly I think I would get a brightness sensor :)

[Rob_in]

Yes.

And when I last reported a bug, instead of being thanked for doing their testing for them, Loxone support just argued with me about how I was using the block in question, didn't grasp my reasoning all while completely ignoring the bug I had found.

I am not impressed.

Robin

[Simon Still]

Although that's kind of what's happened on here as well.  

I don't have  a way of fitting a brightness sensor - there are no spare cables nearby.  And I'm not sure I'd want it - it would, I think, be pretty hard to distinguish a bright winter day when the solar gain is fine from a summers day when it's not.  I could probably configure it over a year or two and get it spot on but what I had works for me. Some of the choices will also be a factor of the blocks available at the time of original coding. 

I don't use operating modes other than Home/Away/Presence simulation.   If there were other functions that I could bundle together I'd obviously think about it as it might make sense. 

I've already got a 'manual intervention override' (don't automatically close or set to shade if the blinds have been manually opened to one side) so they don't interfere with an wide open window.  

This is the full config for blinds (!).  Critique away, but my issue is the 'disable' input on the alarm clock doesn't seem to be working, not that it doesn't deliver the functionality and UI that I want - two objects in the App UI.  A switch between 715 and 1215, and a VI push button to manually open to shade. The rest is automated/invisible.

there are loads of ways of achieving the same/similar things in Loxone. I don't think any are right or wrong if they work.  There's no performance gain to be had - it's just automation and UI.  It's also partly a matter of the blocks in place when originally coded.  and in some cases older blocks have a simplicity and behaviour that meets needs more.  (eg I still have the older lighting block in a few rooms)  

[Jonathan Dixon]

Yeah it's very annoying reporting a bug and just being told it's 'working as intended' when it blatently isn't - I had a very long argument to get the Ventilation controller bug acknowledged several releases ago: it simply stopped functioning for "Cooling support" mode. I had various erroneous push backs from Loxone, from them saying it wasn't intended for that (despite the website advertising this very feature as an eneergy saving benefit of loxone), or that cooling support only works if you have a CO2 sensor (which is obviously not necessary, nor effective to fix it).

Having said all that, in this case I do still think you'd be better off not using Alarm Clock blocks: since you don't want them surfaced in the UI they're overkill for the job. I agree there's no performance benefit to getting rid of them, but there can be a stability benefit in using the less complex blocks. I avoid using the complex UI blocks unless I actually want that specific UI. 

For this scenario my go-to would be a couple "Pulse At" blocks, and either have the radio button control their Off input, or filter the output with AND gate:

 (The whole AND/OR ladder could be reduced to a single IF() Formula block  desired). The "pulse at" duration can be adjusted so the monoflop is probably redundant too.

None of that excuses the fact DisA input has broken for you.

If keeping with the Alarm Clock, you could try using the OFF input rather than DisA ?

--

You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/loxone-english/3a750d75-5478-4113-befc-316a27133473n%40googlegroups.com.

[Simon Still]

Thanks - I did not know about the pulse at block.  That does simply things where you don't want the time to be configureable in the UI (although maybe you can do that with the pulse at anyway if you expose it?). I'd seen all the standard 'pulse at' constants but didn't seem a way to add more.  

You don't need the AND blocks or the OR as far as I can see - >1 link to the input of a block is treated as OR in any case - so can get that logic down to 3 blocks (only using the reversed 'off' for clarity so the lines don't cross) 

[Jonathan Dixon]

> You don't need the AND blocks or the OR as far as I can see - >1 link to the input of a block is treated as OR in any case

Unfortunately that's not always true: connecting multiple lines into one input has differing behaviour dependant on the block in question (and the version of Config in use).

Crucially in this case, connecting multiple inputs to one terminal of an AND block results in them all being ANDed together, not ORed, so the example you give would not work as they're never high simultaneously (well unless both Pulse At were set to trigger at overlapping times).

Similarly Add blocks sum all inputs, and mean, minmax etc apply commutitively across inputs.

In the general case though, for most blocks it is actually "most recent change wins" rather than strictly ORing, for pulse inputs this is effectively the same thing but for anything asserting levels or supplying a numerical value, it can play havoc if you're expecting a strict logical OR.

To view this discussion visit https://groups.google.com/d/msgid/loxone-english/d0371123-17a0-43df-91ea-041824d0eaecn%40googlegroups.com.

[Simon Still]

Yes. I’d forgotten the  AND block worked in that way. 

Covered very well in the documentation. https://www.loxone.com/enen/kb/and/

Sent from my iPhone

On 23 Apr 2026, at 16:45, Jonathan Dixon <jo...@lifelogic.uk> wrote: