Foundation for Loxone replacement?

[Jedi Tek'Unum]

As you are probably aware from my prior posts, I have only recently installed Loxone in my newly built home and I haven't been happy with it. I played with it on a testbed for a year or so and I knew early on that it wasn't going to be something I wanted to use long term.

I share the concerns people have about the increasingly proprietary nature of the hardware and the sudden shift of business strategy towards an all-installer model. Although bad enough, I'm even more unhappy about the software itself - and apparent lack of interest in evolving it. Acquaintances that have had more direct dealing with Loxone representatives have shared with me that they have stated they want to "keep things simple" for their customers (ie the installers). Given as an excuse for their limitations and refusal to make improvements. The most glaring one for me is the lack of "macro" capability. When that is combined with poorly, and seemingly arbitrarily, designed function blocks one has to wonder where their head is at. How can macros not make things easier for installers? Also, to be Windows-only in this age is another example of poor judgement.

This is not to say that there aren't things to like about the Loxone system. As commercial products go its probably the most impressive. For an old software engineer I was surprised at my change of heart regarding visual programming - it has its place and this is one of them. The "live view" is a big plus. Too bad its evolution stopped far too early.

I, and acquaintances here on this forum, have been searching for tools that could be a foundation of a DIY open source replacement for Loxone. There are a surprising number of visual programming (and dataflow) tools out there. Most are of the typical bling type, without much behind them. Others have an architectural philosophy that is somewhat incompatible (for example, Node Red insists that there can be only 1 input per node (apparently fans of Highlander)).

I recently discovered one that seems to have the makings of a winner. Its XOD. Not only is it a visual programming environment but it even supports the model of downloading and debugging a microcontroller (Arduino). It does "macros" (nesting of patches in their terminology) and allows multiple typed inputs. Seems to allow nodes to be written in C++ (and by extension would expect just about anything else). By no means is this a direct and immediate Loxone replacement but it has potential as a tool for doing so.

I would be interested in the community's thoughts and if there are any other software professionals out there with an interest in starting a project.

I have no interest in using Arduino, or anything similarly primitive, for this project. There is no reason to suffer with underpowered hardware or software. My intention would be Unix targets (Linux/FreeBSD/...) on any of the many tiny SBCs available (NanoPi, OrangePi, RaspberryPi, BeagleBone, etc).

[David Wallis]

This makes me chuckle:

I have no interest in using Arduino, or anything similarly primitive, for this project. There is no reason to suffer with underpowered hardware or software. My intention would be Unix targets (Linux/FreeBSD/...) on any of the many tiny SBCs available (NanoPi, OrangePi, RaspberryPi, BeagleBone, etc).

That interesting how you think a arduino or we'll call in a microcontoller (maybe a Texas TM4C123G - as I have experience with these and arduino..) is primitive but you then say about using a SBC with a linux OS rather than something like RTOS,

I moved to loxone from the opensource stuff I was previously playing with specifically because I want my lights to just work and with low latency. A pet hate is where people think a smart wifi lightbulb and IFTT or an app is a smart home.

If you want to move away then I would recommend you decide on what it is you want it to do and then work on building your software / workflows etc and then see how reliable and performant you can make it.

For me my custom code runs the nice to have 3rd party integration stuff that I cant do easily from within loxone - the core of my home will just work with their stuff and so far so good. Not sure why you need macro's though? If you need to do something custom then push that onto other software / hardware you can control.. 

[Simon Still]

On Monday, 11 March 2019 14:12:14 UTC, Jedi Tek'Unum wrote:

 I'm even more unhappy about the software itself - and apparent lack of interest in evolving it. The most glaring one for me is the lack of "macro" capability. When that is combined with poorly, and seemingly arbitrarily, designed function blocks one has to wonder where their head is at.

I'm intrigued - what blocks do you think are missing and what do you want to use Macro's for?  It's always struck me that they've developed specific blocks to the stuff that their installers request in any volume.  So there are blocks for common things like gates and blinds but also for less commonly installed stuff like swimming pools and saunas.  A combination of logic and state blocks can create an interface and display for most other things (though it's not always elegant or simple). Some of them are frustrating in their lack of options (the maintenance counter, for example, will only display total time since switched on, not time to next service) 

If there's a regular combination of actions you want to perform that's easy enough to do using some memory flags - eg I have a button on my Logitech Harmony Remote that sets of a set of activities in Loxone: an infra red input from logitech a) closes living room blinds, b) sets living room cinema scene, c) turns off the lights in the hall and kitchen.    For one-off actions theres a 'task recorder' in the app that seems to let you record a set of actions and set it to happen at a defined time in the future (though there doesn't seem a way to schdule it to happen repeatedly). 

 

Also, to be Windows-only in this age is another example of poor judgement.

It's awkward, but hardly a deal breaker and I can understand why they don't want have to deal with two config implementations.   I'm running a version of Windows7 on my mac as dual boot (got fed up with paying for parallels licences) but a copy of Win10 is only £20 OEM.  

[Jedi Tek'Unum]

On Monday, March 11, 2019 at 10:10:20 AM UTC-5, David Wallis wrote:

This makes me chuckle:

I have no interest in using Arduino, or anything similarly primitive, for this project. There is no reason to suffer with underpowered hardware or software. My intention would be Unix targets (Linux/FreeBSD/...) on any of the many tiny SBCs available (NanoPi, OrangePi, RaspberryPi, BeagleBone, etc).

That interesting how you think a arduino or we'll call in a microcontoller (maybe a Texas TM4C123G - as I have experience with these and arduino..) is primitive but you then say about using a SBC with a linux OS rather than something like RTOS,

What are you trying to say here? Arduino is primitive. RTOS are primitive. I have no delusions about Linux and my professional opinion* is that its not the best in the world either. But it is sadly becoming the de facto standard for everything. In the context of an SBC my preference would be FreeBSD.

I moved to loxone from the opensource stuff I was previously playing with specifically because I want my lights to just work and with low latency. A pet hate is where people think a smart wifi lightbulb and IFTT or an app is a smart home.

Agree that the vast majority of what is called smart is stupid. Anything that depends on a round trip through the internet is the worst.

If that is your reference then I can see your concern about latency and not working reliably. Arduino or an RTOS will certainly be lower latency and reliable. So will Linux/FreeBSD/... I've got a NanoPi Neo2 running Linux and my custom software interfacing to my custom button hardware and 48+ LVSW buttons/LEDs with Loxone notification via UDP. Nothing of concern latency-wise. Is Linux rock solid? I'll comment on that after I figure out a minor problem that shows up after hours of running (maybe hardware or maybe Linsux). As soon as I get a FreeBSD running on it with the correct GPIO and I2C configuration then Linux will be gone.

If you want to move away then I would recommend you decide on what it is you want it to do and then work on building your software / workflows etc and then see how reliable and performant you can make it.

For me my custom code runs the nice to have 3rd party integration stuff that I cant do easily from within loxone - the core of my home will just work with their stuff and so far so good. Not sure why you need macro's though? If you need to do something custom then push that onto other software / hardware you can control.. 

Right at the start I have a button usage scenario that doesn't seem to map directly to any Loxone function block(s). Repeated presses within some time interval steps light brightness through a range. After the interval has passed the next press shuts the light off. One would think a virtual input driving a switch driving a dimmer driving a DMX light would do it. Doesn't appear to be possible. So that requires logic and half a dozen or so function blocks. Now repeat that for dozens of circuits and immediately it becomes an unmaintainable mess.

As a side, why does an EIB Dimmer not have a Reset input?

Sure, I could shift the smarts to the button system. There are other cases - do I deploy yet another kludge to overcome Loxone each time? What does Loxone become then? A UI and central switchboard? I'd rather discard it entirely.

* professional opinion -> ~40 years of software engineering/architecture at Fortune 500 hardware and software manufacturers.

[Jedi Tek'Unum]

On Monday, March 11, 2019 at 2:33:09 PM UTC-5, Simon Still wrote:

I'm intrigued - what blocks do you think are missing and what do you want to use Macro's for?  It's always struck me that they've developed specific blocks to the stuff that their installers request in any volume.  So there are blocks for common things like gates and blinds but also for less commonly installed stuff like swimming pools and saunas.  A combination of logic and state blocks can create an interface and display for most other things (though it's not always elegant or simple). Some of them are frustrating in their lack of options (the maintenance counter, for example, will only display total time since switched on, not time to next service) 

If there's a regular combination of actions you want to perform that's easy enough to do using some memory flags - eg I have a button on my Logitech Harmony Remote that sets of a set of activities in Loxone: an infra red input from logitech a) closes living room blinds, b) sets living room cinema scene, c) turns off the lights in the hall and kitchen.    For one-off actions theres a 'task recorder' in the app that seems to let you record a set of actions and set it to happen at a defined time in the future (though there doesn't seem a way to schdule it to happen repeatedly).

I'm not thinking of macros in terms of performing a set of otherwise unrelated operations.

When the blocks available don't perform a function as desired then the only choice in a closed proprietary system is to build a macro block. The example I just gave in the prior post - stepping brightness with off after a time period has passed.

 

Another example is brightness stepping in a manner other than a fixed step. (Plus there is no 'log' function block so even that would need hacked custom logic.)

Another example is LED fixture brightness. I have cases where I'm using some as night/path lights. I want them absolute minimum brightness that the fixture is capable of. Almost(?) all AC powered dimmable LEDs require a higher initial setting to get them to light and then they can dim lower. Where is this supported directly in Loxone? Nowhere. Custom logic could do it but need macros to make it practical.

 

After ~40 years as a software professional I'm 100% certain one doesn't make product vision or design decisions based solely on the customer base. When you do you get exactly this swamp of poorly engineered function blocks. In this case, installers are not software professionals and in general have no idea what good UI or functional design is.

Also, to be Windows-only in this age is another example of poor judgement.

It's awkward, but hardly a deal breaker and I can understand why they don't want have to deal with two config implementations.   I'm running a version of Windows7 on my mac as dual boot (got fed up with paying for parallels licences) but a copy of Win10 is only £20 OEM.  

 I'm running Windows7 Pro under VirtualBox on my mac for this. Not a deal breaker but inconvenient. The right thing to have done would have been to implement in Java from the start. Yeh, I know people hate Java for various reasons. But the bottom line is that a single codebase can have a fairly complex UI with decent quality on Windows, Mac, Linux, ...

[Jedi Tek'Unum]

On Monday, March 11, 2019 at 3:44:34 PM UTC-5, Jedi Tek'Unum wrote:

The example I just gave in the prior post - stepping brightness with off after a time period has passed.

Just to clarify the use case...

With a single button, turn light on at minimal brightness and not require stepping through full brightness to turn off. Middle of the night path lighting for example. Really undesirable to have things bright. Can't depend on a fixed amount of time to automatically turn off. (And still want to be able to get to full brightness with same button.)

Within the first N seconds (5 in my configuration) each press of the single button increases the brightness by the step (say 20%).

After 5 seconds from the first press has elapsed, the next press turns the light off.

I am fairly new to Loxone and it is possible that I've simply missed the function block that already behaves this way. If so then I apologize for using this as an example in my rant. It wouldn't, however, change the rant.

[Andrew B]

That’s more or less the same as the button logic I’m running. That controls the target light dimming level, then my software generates DMX frames at 40 Hz until it achieves the targets. I also have a bit of snazzy rgb support to make colour fades a bit more interesting. :)

4-core 1Ghz runs this under Ubuntu 16.04 using about 5% cpu typical, with a peak of about 10% during normal operation. If I really go nuts with animating the tape lights it gets up to 20-30%. Latency is way shorter than is human perceptible, and I’m pretty sensitive to such things. Memory use is pretty low, nowhere near the SBC’s RAM... can compile my program multithreaded on the same machine without impact to how the house is working. At the moment my time series database and Grafana run on another 8-core machine ~1.5 GHz, but eventually I’ll get around to moving it all onto either that 8-core 32b or else I’ll have a 6-core 64b machine with 4GB RAM running by that point. Oh, also have MQTT and HomeKit integration on there too. Next though, I’m focused on moving my HVAC logic from the Loxone to the SBC, leaving the Loxone only for its GUI. Not that much work left to get there, I’ve just been going slow for unrelated reasons.

My code is all C++ because I’m an old school C++ hack (read: software engineer) and Python and Java make me nauseous with their gross inefficiencies. I’m still running a debug build, so performance in an optimized build will be even better. These little machines, even running Linux, are vastly better than you really need and kick the heck out of the miniserver for waaaaaay less money.

[tkn]

I am not surprised. Loxone is definitely an 80% solution and they are more focused on selling to the installer market than anything else at this point.

I am still fine with it because I don’t have time for projects like that right now. And I don’t want a system that has to be ripped out when I move. Although I suppose you could program a dumb mode where things just turn on and off at switches.

I’d prefer a better PAC so I didn’t have to run a Raspberry Pi on the side for functionality. I’d want something open source with wide adoption. Something that perhaps has the same general philosophy as Loxone in that the defaults are logical and sensible and easy to work with. If Loxone is trying to be the Apple of home automation in choosing lots of defaults, I’d rather see the Ubiquiti equivalent I suppose. (This comparison is very flawed but I couldn’t think of a better one off the top of my head)

[Andrew Brownsword]

This: “I’d want something open source with wide adoption” is a really important point. The more and more complex your dependencies, the bigger a nightmare you’re going to have in the future. Tons of open source projects come and go, even if they get very popular for a while. Choosing which to use is very challenging. I chose one major dependency, and the rest are all very lightweight and thin. None have secondary dependencies. I’m also using a language guaranteed to have a long life ahead of it, and the most widely used OS in the world (Linux). Keeping the software portable between ARM and x86, and 32b vs 64b. Have some interfaces to other external systems (eg HomeKit and Postgres) which are optional and easily replaced with some other equivalent. Similarly, interfaces to other hardware by common standard (Ethernet) and software modules designed to be easily replaced or adapted to new devices.

Same philosophy in hardware. Modular system, easily replaced components, stick to very common and well established standards.

Not writing to advocate my choices, just pointing out some considerations that don’t seem to get enough attention. Much like failure mode handling. These systems ought to live for 20+ years, which is no mean feat!

> --
> 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/ypsi-jFj8RE/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/466adf94-d1da-4af4-ab19-073557ead018%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Peter van Es]

Gentlemen,

I'm technical myself. I understand some of your issues. I experimented with all sorts of hardware and controls, until buying into Loxone. Why? 

• I'm married. My wife is not interested in tech, she wants something that just works. Loxone, despite it's imperfections, is that;
• At some point in the future, I may want to sell my house. The domotica installation included. I want it to add value to the house, not detract from it.

Any solution that is only understood by you, that cannot be maintained by anyone but you, will detract from the value of the house. The fact that there are independent installers/maintainers of a Loxone system mean that you can point this out, and will reassure the future buyer of your house.

If you decide to change the programming model to something unique that is technically better for you, you are just satisfying your own needs. Not those of your family or future house owners.

Good luck. However perfect your solution is, if there is no support available in the market, then I'm not buying into it.

Peter

[Rydens]

Very interesting read - thank you. 

Agree with need for a Loxone macro capability - you can do most things with the logic as it is, sometimes pretty convoluted, but when you repeat it several times it becomes very messy. 

Also agree the need for a few options on the lighting controller - like why can I not suppress the change in v2 that a click on a selected scene goes to the next scene, and agree on need for start up with back off to minimum brightness. 

Loxone is also getting behind with the lack of voice integration with Alexa / Google Home. Although I find voice has limited uses, you need the ability for quick simple actions. Others are adding it - Loxone will fall from favour without it as customers will think they need it!

I will say however, Loxone does work - and when you press a switch the lights come on with no delay. It is also pretty much self documenting. 

Upgrades are painless and so far always work.

The kit and addons are good quality, but expensive. 

Although mine is a self install - I know if anything happened to me there are companies out there my wife could go to for support, and when I sell the house it is a valued add on. 

I also run raspberry Pi addons to more effectively control Sonos and to open and close Somfy blinds. 

Have recently discovered open source Home Assistant which has lots of capability, but is more complex to configure - however more options!

I too come from 40 years in IT but I like high level languages that let me do things quickly - like Python. 

Cheers David

On Monday, 11 March 2019 14:12:14 UTC, Jedi Tek'Unum wrote:

[Arnaud]

Hello,

As an installer I can understand your frustration, but it is indeed the business model that Loxone has chosen: to rely on a network that ensures the deployment and promotion and not the DIY community.

As has been said, it should not be forgotten that commercial solutions like Loxone are designed to ensure that everyone can enjoy a smarthome and not just IT engineers.

Personally I tested a lot of solutions before choosing Loxone, and yes it's true that there are evolutions that we would like to see happen, and yes we would like to pay a little less, on the other hand... what a joy to never have to debug..... when I press... it works... and that's all the typical customer wants, he doesn't care how technical it is, how many cables it takes, etc..

I confirm that Loxone has made the choice to frustrate people like you, so that professionals can install reliable solutions with complete peace of mind.

I know many of them who have OpenSource solutions... their Saturdays are not as pleasant as mine, that's a certainty, after, yes, when there is no bug, they drive more things than I do, to see, but on the side of my customers, they don't want to play with their house, they just want it to be simple and reliable.

I mean, there are certainly things to improve at Loxone, but starting from scratch to get to the minimum where they are........ good luck....

Translated with www.DeepL.com/Translator

[Colin]

This is a very interesting discussion.  

It is quite right that Loxone wish to promote and build a good partner installer network; further that that is their primary route to market.   As has been pointed out: this means that we can sell our Loxone based homes knowing that the new owners can continue without having to rip it all out and start again.  Very important.  It also allows Loxone to sell to the vast majority of people that don't want to delve into the tech.

However ... equally important is that Loxone don't force a homeowner to go to a partner for everything.  A smart home by definition embeds some of the home occupants lifestyle within the system.  That can and often does change.  It is important that Loxone permit as much as possible to be configurable by the system owner.    They get this right in some areas (e.g. adding timed events or schedules).  However they still require access to the Windows configuration for too many important items.   The example of macros has been mentioned.   Another good example is the Loxone smart socket - which cannot be added or moved from room to room without configuration.  This prevents the owner from adding something simple like a side light without either doing config or calling the partner.

I think this tension is made worse by some partners that try to lock in their services by not revealing the configuration password to the owner.  I am sure not all partners will do this but I have experienced this problem myself.

Getting this balance between partners and system owners is critical.   At the moment I think Loxone have it about right.  I really hope they don't swing more towards partner-only.   And that they really consider how much they can allow the system owner to do without having to call a partner.  These two things are not exclusive options.

[Andrew Brownsword]

This is a great point, but don’t fool yourself into thinking the Loxone solves it.  A Loxone based solution is just as proprietary, and even if you have an installer offering support that person isn’t going to be around forever.  If a company is behind it that’s better, but a lot of these shops are fly-by-night little outfits.  Loxone’s attraction is really that you can pick it up and support it yourself... so you’re right back where you started.

--

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/ypsi-jFj8RE/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/efa479a1-8763-49d1-84c8-b99f5dc677cb%40googlegroups.com.

[Jedi Tek'Unum]

Thanks for the discussion. I just want to clarify my position(s). I'm in the USA - Minnesota.

I've purchased Loxone and have it deployed. I could have written my own from the start. I chose the Loxone path because it had value to me. It turns out that the value isn't as high as I had hoped. There are many flaws in the design which could be entirely excused if there was an ongoing effort to evolve into a better product. If they could do that I would be willing to pay for major software upgrades and even upgrade the MiniServer at some point.

I don't want this thread to devolve into a DIY/installer conflict. I personally think that issue is totally bogus. But it doesn't matter to me - there are no Loxone installers here.

The cost of Loxone isn't even of primary concern to me. My issue is that its not doing the job. If they won't fix it then I'm going to look for alternatives.

I agree with the concerns about selling a property in the future with a custom automation setup. It concerns me too. As I said, there are no Loxone installers to be seen. Maybe there is somebody that does Crestron around here but its mute because I can't afford that. I will not use the commodity junk out there. I'm disabled and need automation. What other option do I have?

I value my time and building a custom automation system is not high on my list of things I'd like to be doing. I live in an unserved market. Both literally (no custom installers) and demographically (technically savvy but not massively wealthy).

I'm in my late mid-life. I may be from a technology education and career but its pretty obvious that the younger generation is much more technically oriented than many recognize. Just wait until you try to tell a millennial that they have to hire somebody to reprogram a light switch. Today they are snarfing up the typical commodity junk that promotes itself as automation. They will grow older and will become more demanding (robust always-works technology). Then what?

[tkn]

Jedi - you and I have corresponded a lot about this, so none of this surprises me.

Loxone has made some absolutely terrible decisions, including software stagnation, the closing of their model to appeal to installers, their move to proprietary protocols like Loxone Air, not supporting Alexa and Google natively, etc. They definitely aren't in the conversation against Crestron or Control4 or Savant, and I doubt they will get there. They would need to start signing partnerships with just about everyone at the least, and they really haven't done any of it.

I think having a custom solution is risky - what happens if you die and your spouse or someone else is left with it? Every time you might want to do something new, you know you are going to be left with doing the heavy lifting yourself. With Loxone, at least you could hire someone remotely to do some debugging, scant consolation as that might be.

Maybe something like OpenHAB would be a better base to build on - I don't know. At least there are active users out there that could be found to help support the software later.