Custom block? Function? Subroutine? Or lots of copy/paste? :(

[Rob_in]

Hi all,

In our main living area we have shutters on all the windows and naturally have lighting in a few areas. I wanted to avoid having to put dedicated shutter controls everywhere because I feel shutters can mostly be left in autopilot. That said, I want the ability to override shutter controls once in a while. To this end I came up with the following scheme:

- Switches work in one of two modes: light control or shutter control.

- You alternate between the two modes with a long press of any part of the switch.

- Once in 'shutter' mode, after 10s or so of no input the switch should revert to 'light' mode.

- The switches (they are Legrand Celiane KNX) have illumination behind them which can be programmed to light up in different colours based on the mode.

- When in 'shutter' mode I want the illumination in the switch to be always on (I used 'gold' to indicate shutter control).

- When in 'light' mode (I chose a blue switch colour to indicate this more) I only want the switch illumination to be on if the room is dark.

This is all relatively easy to do. I created 8 virtual inputs (represented by memory flags) and when the physical input is pressed (tapped as opposed to a long press which changes mode) that causes one of the virtual inputs to be triggered which can be used to control the lighting or shutter control as required.

OK, it's not that simple ;) I had to do this in two pages (attached for your amusement). The more complex page is the part to work out 'mode' and control switch illumination. The other is just to take the input triggers and pass to one of the 8 virtual inputs (memory flags) I mention above.

Side note: One oddity I found with the 'long press' block is that you cannot have a simple long press. You have to use the 1x, 2x, 3x & 4x levels, so it's best to set a rather low timer and have 1-3 trigger the same output and then 4x represent your real 'long press' output. If you just try and use 1x & 2x then it can be a bit tricky to hold the button at the right duration rather than just anything longer than a 'tap'. I hope you know what I mean.

Anyhow, after all that preamble my question: How does one replicate this logic for multiple switches in Loxone? In a classical programming language this would be easily done with a function, subroutine, etc. In Loxone I would love to be able to create a 'custom block' which took both these pages and encapsulated it in a single block with 4 inputs and 8 outputs.

Sadly I think you are going to tell me there is no way to create functions or custom blocks in Loxone and I'm just going to have to copy/paste the pages for each switch. This was one of my reservations before choosing Loxone after seeing it's graphical configuration tool, but I carried on regardless. I know it can be done but am just looking for a smarter way if that exists. BTW, I have been working in software development for close to 30 years and much prefer to write code with a keyboard. Call me old school ;)

Cheers,

Robin

P.S. Happy to hear suggestions as how this could be done differently if anyone is keen.

[seb303]

You've come across one of the big limitations of the Loxone system when it comes to scalability.  Copy and pasting everything is a pain since all the I/O then needs manually updating, and of course the bigger pain comes when you want to tweak your repeated functionality a bit later.

Personally I would be tempted to use a single Custom Program block and code the functionality in PicoC.  Since you are limited to 8 (well actually it's 7 currently due to a firmware bug) programs, it's not practical to have 1 per room.  So you'll need to code everything in a single program.  You can get around the I/O limitations of the block by reading/writing Inputs, Virtual Inputs, etc. directly.  This is a somewhat undocumented feature: anything with a "Connection" value can be read or written with functions getio or setio.

Seb

[Duncan]

here ive used a single long click from multiple buttons to trigger a flipflop (the timeout to swap button function, say 15 seconds) and just used and blocks to enable/disable the buttons

pressing any button normall passes the clicks to the lighting block, a long click triggers the flipflop which disables the inputs from the lighting block, but enables the inputs to the blinds block - it also swaps over the appropriate led output and flips back to normal after the timeout set by the flipflop

[Rob_in]

Nice... but how do you stop the pulse from a long click action (when you want to switch modes) from getting into either the light or blinds controller causing something to happen with one of them when all you really want to do is change mode?

[Aleš Berka]

Hi Rob,

please contact Loxone support with this feature request. I have requested something very similar (to encapsulate a group of controls and relations between them into a single custom made function block):

Visualization

But it has been refused with following reasons:

- very rarely used

- problematic implementation

- against Loxone Config philosophy

Please do keep opening tickets like this, to debunk the myth that this would be rarely used. The other reasons are just a lame excuse in my opinion.

Best regards,

Aleš

[Rob_in]

Do they even have a ticket of feature request system? How do I log this?

[Aleš Berka]

Yes. Just write an e-mail to address mentioned here: https://www.loxone.com/enen/support/

The ticket gets autocreated and the rest is done via their support web.

[Simon Still]

On Saturday, 4 February 2017 08:25:11 UTC, Rob_in wrote:

Side note: One oddity I found with the 'long press' block is that you cannot have a simple long press. You have to use the 1x, 2x, 3x & 4x levels, so it's best to set a rather low timer and have 1-3 trigger the same output and then 4x represent your real 'long press' output. If you just try and use 1x & 2x then it can be a bit tricky to hold the button at the right duration rather than just anything longer than a 'tap'. I hope you know what I mean. 

Yes, I've ended up doing the same thing whereever I've used Long Press - it's not at all user friendly to try to have more granular control.  Effectively you end up with press, long press, very long press (hold until action).

I can't help thinking that Loxone need to overhaul the basic button block - it shouldn't be necessary to have the complex combination of switch, multi-click and Long press - a single configurable input block would make a lot more sense

[Rob_in]

FWIW, I opened a ticket with Loxone support regarding this.

[Andrew B]

I consider doing this at the scale of a house infeasible with the graphical approach. I struggled to get the logic to even work at all, and then faced the problem of replicating 80 times completely insurmountable. I even considered writing a program to generate the xml project file behind LoxoneConfig's back. Even if you manage to do it, you're then faced with a maintenance nightmare.

My first solution was a picoC block, and we ran with that for a year in the house. Developing the code was a bit painful, but doable... before it was installed and the house occupied. Now that it is installed and we live in the house, the development process is far to stressful and buggy to cope with.

As a result I'm now doing my development on an 8 core Linux system with >300GB flash storage, 2GB RAM, Gig Ethernet, USB, C++14, and full debugging support. This is about a million times better for writing code, and with a single picoC module and some virtual outputs I have pretty seamless communication between the Linux, Elexol I/O and Loxone devices. The Linux device cost me $50 and draws less than 5W.

[Rob_in]

The thing is... once you stray from 100% standard Loxone programming you might as well ditch it and do something completely homebrew.

I want a system anyone with Loxone skills can maintain. That was one of the reasons for choosing it in the first place.

All in or all out.

FWIW there are only 6 switches in our house I want to utilise like this. It's easy to do one then copy paste. Time consuming, but easy. Yes, I wouldn't want to do it 80 times though!

[Jedi Tek'Unum]

IMO Loxone risks exactly that - a group of us starting a project to create an open source solution. The lack of "macros" is a glaring omission that only increases that risk.

Its obvious Loxone is on the path of becoming more proprietary and dealer focused. Inevitably that leads to handicapped products and operating style that fits their idea of what that market is. Volume requires simplicity. They won't want to have multiple styles of lighting operation for example.

Its no different than Apple or any other product - if you don't like how something works, too bad. Where are you going to go to find a product that is significantly different? Unfortunately, open source and/or homebrew has its own set of problems.

I really hope version 9 has macros but the odds aren't good.

[Jedi Tek'Unum]

On Friday, September 22, 2017 at 8:53:59 PM UTC-5, Andrew B wrote:

As a result I'm now doing my development on an 8 core Linux system with >300GB flash storage, 2GB RAM, Gig Ethernet, USB, C++14, and full debugging support.  This is about a million times better for writing code, and with a single picoC module and some virtual outputs I have pretty seamless communication between the Linux, Elexol I/O and Loxone devices.  The Linux device cost me $50 and draws less than 5W.

This isn't the Wandboard you mentioned in another thread. What is it? 

[Andrew Brownsword]

I started on the wandboard because I had it on a shelf and it works well.  I just received an odroid HC-1 which is ideally suited to my project.

I'm still making good use of the Loxone, but their refusal to enable a good programming environment is very limiting.  Now that I have the HC-1 I'll be moving my telemetry to that along with the complex logic.  Depending on their future direction I may move further away from their system, or may not.

--
You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/Ex3qjID73Zs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to loxone-englis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/0043d64f-7602-4979-a692-635031c36e28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jedi Tek'Unum]

Ahh. I had seen that before. Interesting form factor with the SATA. Also an odd duck with the two different quad cores - probably not supported by FreeBSD (my preference).

Although quite a bit more expensive, I’m considering a Celeron or Atom system. Recent ones are pretty low power. And best of all - more straightforward O/S support. Jetway or Zotac or… Expensive is relative and they are less expensive than the MiniServer!

Since I’m considering these approaches, I’m also considering not using the Elexol. I’ve ordered a couple of the new Phidgets.com devices - the 16x isolated digital input and the 32x LED driver. They interface through their VINT hub to USB.

The only Loxone thing that is difficult to replace is the graphical programming tool. Could be done with enough time/effort.

[Rob_in]

On Saturday, 23 September 2017 17:19:22 UTC+2, Jedi Tek'Unum wrote:

Since I’m considering these approaches, I’m also considering not using the Elexol. I’ve ordered a couple of the new Phidgets.com devices - the 16x isolated digital input and the 32x LED driver. They interface through their VINT hub to USB.

That LED driver doesn't look like it's designed to drive ceiling lights.

 

The only Loxone thing that is difficult to replace is the graphical programming tool.

That's handy, because it's the thing we're complaining about here :D

Robin 

[Jedi Tek'Unum]

True. I'm getting it to try with the LED indicators in the Wattstopper switches. Probably have to remove the resistors in the switches as its meant to drive raw LEDs.

[Andrew Brownsword]

I just drive the WattStopper LEDs with a DC-DC converter.  I found that 24v made them stupid bright, while the 5v I'm using is plenty in the dark (although I leave them off most of the time as we like it very dark).  I have the whole house worth of switch LEDs on a single relay.

Phidgets look cool.  I'm happy with the Elexol products, and Ethernet is very advantageous.

The latest gadget I'm contemplating is the Burltech GEM.  That'll let me track energy use throughout the house in glorious detail.

Anyhow, going way off topic here....

--

You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/Ex3qjID73Zs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to loxone-englis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/4da30e45-8b09-479f-abb4-42a18f092e89%40googlegroups.com.

[Andrew Brownsword]

The heterogenous cores are known in the ARM world as "Big.little".  The FreeBSD website lists the ODROID processor in the supported list.  I haven't tried FreeBSD, but the ODROID Ubuntu 16.04 image with the 4.9 series kernel fired right up and I was installing packages within minutes.  And this sucker is FAST... my code builds speedily.

The ARM SoC also includes a Mali GPU with full OpenCL 1.2 support.  Since I'm contemplating doing some AI on the device, this may come in useful.

In any case, the point is that compute is plentiful and very cheap these days.  Keep to portable software and non-proprietary code, and you should be able to find replacements economically forever.

--
You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/Ex3qjID73Zs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to loxone-englis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/122be7d2-045c-46e4-b394-e31bdb14313a%40googlegroups.com.

[Jedi Tek'Unum]

I am contemplating trying some smarts with the LEDs. Mode selection indicators; acknowledgement blinks; various blinking rates; heartbeats; dimmable; etc. Actually, it will go up to a little over 5V so it should be enough to drive without removing the resistors.

My luck the Phidget won't be compatible. They show it connecting to each end of each LED separately. The Wattstoppers have common cathode.

[Jedi Tek'Unum]

Phidget testing results for anyone who cares...

The Phidget 32x LED driver is not compatible with Wattstopper switch LEDs as-is. It expects both leads of each LED raw; common ground won't work. Appears to be a open collector style that is typical of many control circuits. The Wattstopper only supports common ground for LEDs. Of course someone intent on making it work could - by attaching an optoisolator to the Phidget and then controlling the high side of the Wattstopper LED. The other issue I found was that at least on the Mac GUI I couldn't change the output voltage without an error so it was locked at the lowest setting (3.2V if I remember right); the highest setting would have been something around 5.6V which may, or may not, be sufficient brightness depending on personal preference. The optoisolator would also allow higher drive voltages.

The Phidget 16x Isolated Digital Input works with Wattstopper switches assuming one adds a pullup resistor to each channel. I believe the scan rate is <100ms. Appears it would be necessary to implement debounce in software.

The Phidget software requires some low level USB stuff. They supply for many platforms including Mac and Linux. No direct claim of support for FreeBSD but I've read elsewhere that it is fairly easy to use the source supplied with the Linux distribution on FreeBSD.

In my opinion this is another option along the lines of Elexol. Instead of an ethernet interface it provides USB. If one is using an intermediary box like Andrew is, either approach is workable.

For me this still isn't an optimum solution as it stands. Once again I may have to create a custom circuit.

As a side note, I'm leaning further towards an x86 based SBC for my intermediary. In particular, UDOO X86. Its a lot more capacity than is needed obviously but I'm seriously thinking I will be phasing Loxone out over time and implementing my own on this box.

[Jedi Tek'Unum]

On Saturday, September 23, 2017 at 11:43:14 AM UTC-5, Rob_in wrote:

The only Loxone thing that is difficult to replace is the graphical programming tool.

That's handy, because it's the thing we're complaining about here :D

I was hoping V9 would provide macros. But it seems we got visual enhancements.

While it would be difficult to replace it wouldn't be impossible. I am certainly capable of creating a Loxone-like clone using off-the-shelf hardware including a similar kind of GUI. But it would consume a fair bit of time. I don't have that kind of time available now but once I get my home built and settled in this might very well be high on my priority list.

Perhaps there are others on this forum with the skills and time to contribute to such a project. 

[Andrew Brownsword]

There is at least one open source home automation package to build upon.  Starting completely from scratch would be an enormous project, but given how many open source pieces are around these days it should be doable.  Integration with things like HomeKit will help too.  I may eventually go this way, but getting there incrementally is much more manageable.

--

You received this message because you are subscribed to a topic in the Google Groups "Loxone English" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loxone-english/Ex3qjID73Zs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to loxone-englis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/d88debd3-be8a-4f8f-bc45-f1f574b0cc5b%40googlegroups.com.