Sure but, maybe as an enhancement but I think the first step is on premise Primary/Secondary. Some people don’t want to use the cloud services for fear of security nor would they want the latency of all commands previously on premise to now go up to the cloud and back.
1 Like
I would like that feature, although my use case could be solved as simple as allowing multiple secret hashs to link to the same account… I have two identical ARM based boards setup with identical loads of openhab with the intention that I can swap a faulty hardware SBC out and install the second one and the system comes back up perfectly. Currently the SECRET and other hash stop this working so I can not get my wife to swap out the faulty hardware without my needing to login and change some codes over. If I could pre-approve both of my hardware units this would make things far easier.
I have read the code in detail. Basically the cloud connector is a proxy that just forwards the REST api requests back and forth between your Openhab and your web browser. It does get more complex with the expose feature that is turned off currently for IFTTT support, plus it handles the SMS text sending and tags to google home and alexa.
Since it is currently a “dumb proxy”, It just passes any calls to your internal network like you are using the user interfaces or REST calls from any browser inside your network.
I hope that makes sense? Probably easier to suggest the apps get the ability to display a nice list of the homes you want to connect to and setup multiple logins one for each home.
To put a suggestion forward you would need to come up with a concept that multiple devs would support as it means changing the framework and that is the hard part, not as simple as dropping in a jar file.
Can’t you just make each device have the same UUID & SECRET ?
Unless you intend to run both at once?
Or if you’re testing one, while the other is running, just swap the UUID files as the last step before powering off your “spare” machine.
I tried that and it did not work. I guessed it was the uid and secret are based from hashes off the hardware. Copying the files over did not result in a working remote system, but I have not tried it in a few years so I could be wrong. If anyone is doing it then please post.
It’s incredibly difficult to maintain a working taxonomy on code libs/snippets, let alone when they originate from different sources, of differing levels of quality, documentation, comprehensiveness etc. and from various people to maintain their contribution or not because they lose interest.
Just my personal $0.02, but I’m sure most devs see it that way, too.
BTW the devs are the wrong people to address this to. If any it’s the community here.
YMMV, but gladly this is an Open Source project. So jump the barrel and start contributing yourself if you believe it is worth the effort. The code samples are all here on the forum.
If you come up with a feasible prototype, I’m sure maintainers will be willing to provide you with the infrastructure (server, DB) it takes.
Yes just as @rossko57 states correctly, this has been beaten to death, and for good reason.
No newbie needs it. If you think you do, you can do it with MQTT.
Yes it is complex but that it will remain to be and it is wrong and self-referential to ask this from the openHAB core devs rather than to do it yourself.
It’s completely against the architecture whose fundamental precondition is reliable connectivity (on IP,RF, whatever) so it makes no sense to build it there, putting the whole project at a risk if you start changing the core architecture - and that just for edge cases where there’s alternative solutions.
So please stop raising this again and again. YMMV, but the dev’s and contributors’ view on this does not so it’s just waste of time on everybody’s part. Better invest yours into getting MQTT to work.
“But I want two independent but interlinked systems!”
“But I want a Live and a Failover warm backup!”
“Oh … but I want a hot backup, full parallel running!”
“But I want to link two premises!”
“But I want three!”
And with the necessary choices and flexibility comes complexity.
If i was a developer with the skills Id have done it long ago mstromi.
In my eyes these are basic functionality that should be part of a proper home automation platform. Scheduling, being able to link devices, rule libraries for people to use etc. I’m happy to contribute everything Ive got but im no developer so I cannot build what you ask.
This was one idea behind NGRE, to be able to create reusable rule templates. If i rembember correct, this is still planned…
1 Like
I was referring to the MQTT solution. You don’t need developer skills for that. Those skills you need in turn for MQTT you are expected to learn, just like any user is expected to.
In your eyes only, that is. But probably any dev and advanced user like myself disagrees.
Please accept that and that noone will take on it - once and for all.
And I wouldn’t think I need to repeat that this is an Open Source project and any core dev and contributor is free to choose for himself what he thinks is right and most important to work on.
You must not urge and annoy anyone to build a thing they consider to be a bad idea. Let them do their job.
As I said, that’s just waste of time on everybody’s part so please stop raising this again and again.
To provide the technical framework it takes I think yes.
But that’s just a minor part. It takes much more to build and maintain a database of user-contributed code: spare time, willingness to review other’s contributions and dedication - else that ‘project’ will quickly run dry. And it’s more likely to happen with Python rather than Rules DSL.
-
This is what will NGRE do. I think this will greatly improve the usages of rules (and complexity) used by newbie users.
-
These might be great, but I also think this will be used by a minority of the users.
I consider myself a more of an advanced user and still I just use one instance / house.
However adding more instances to one account in myopenhab and be able to access them in one place might be a better first suggestion. And also might not be that hard to implement.
Also there are still other minor things in openHAB which could be a better suggestion and not that hard to implement.
Like existing Things should automatically show new channels in case an update added new channels to the binding rather than having to delete and recreate that Thing.
Or for example the startup of openHAB could be improved so that these unexpected errors would go away. This is a more trial thing as you can see this here on the forum. Almost every day someone has some problem which can be related to startup sequence…
1 Like
It’s not a waste of everyones time, its just waste of your time so feel free to take your negative comments elsewhere. No one is forcing you to reply. The forum is littered with comments about users having zwave issues and looking for solutions. This is certainly one of them. Zwave has limitations, this can help solve them. Clearly if there was alot of debate about this, then alot of people see its usefulness. If no one wants to develop it fine, thats cool. its after all a suggestion.
FYI im using MQTT and Openhab linked just fine, it works well. But for a first timer, or someone who doesnt have years of experience with OH its complex and time consuming.
2 Likes
Multiple openHAB for this purpose is a circumvention, not a solution. A solution would lie within zwave itself e.g. repeaters, bridges.
Consider that a more generally useful “solution” could be the ability of a single openHAB instance to reliably use multiple remote zwave controllers.
The usage of MQTT linkage that seems to me to be most prevalent is linking two genuinely remote instances e.g. home/workplace , home/holiday home. If you need a use-case, build it around demand.
Definitely so. Or ser2net or any Z/IP gateway.
@dastrix80 why do you call your post “Suggestions for openHAB” when actually you mean to ask for a potential solution to your or somebody elses zwave problem ? You’re making us victims to the XY problem here. That’s where you wasted all reader’s time, not just mine.
This is already available for Scripted Automation and I expect what we have now or something better will be available in OH 3. There likely will never be such a library or system for Rules DSL. The language simply does not support it now and it’s unlikely to be modified to support it in the future.
I welcome any improvements to Marketplace MQTT Event Bus. When using scripted automation, all that is required is importing the library and adding your Items to the right Groups. I’ve plans to convert this to a Rule Template but am waiting for OH 3’s new UI first before I spend time on that.
The problem is it’s not so simple to set up because the only way to avoid infinite loops requires details about the system that only the user knows ahead of time. Therefore some assumptions simply cannot be built into the bus and must be left to the user to configure. I’m not saying that the 30 or so lines of Rules DSL code above makes it as simple as it could be, but based on my experience building those Rules and the Python library equivalent, it’s never going to be as simple as providing a url for the “slave” OH instance and it’s done.
Obviously, someone can convert the Rule I wrote into a binding, or as an addition to the MQTT binding, but at the end of the day, the user will still have to identify which Items to share and how to share them and be careful not to create infinite loops. That’s where the complexity lies and that’s the part that can’t be avoided.
@dastrix80 actually has a valid use case. But I do take your point, it’s probably not something a “newbe” should be worrying about. I’d have it as an advanced topic.
I see two problems with this.
-
It forces users to be reliant on a cloud service for this feature, even when both instances are on the same network. That would not be a satisfactory approach for many users.
-
The whole reason that IFTTT integration was shut down is because too many users were sharing all their Items with the Cloud Service. I’m very hesitant to introduce something that would exacerbate the problem.
It does have the advantage of making it easier to integrate two instances that are on different networks without setting up a VPN or the like though. Maybe there would be a way to do it more efficiently than it’s currently done.
But we are still left with the problem that user is going to have to be knowledgeable and careful in how they expose what Items to avoid infinite loops. And that’s the root of the complexity.
One flaw with this argument though is that one of the justifications for the removal of support for 1.x bindings in OH 3 is the ability to federate an OH 1.x or OH 2.x instance with OH 3 and have the users run their OH 1.x bindings on those older instances of OH. So there is coming down the line a use case for even newbie users to be able to as simple as possible federate two instances of OH. The strength of that need will depend on how many 1.x bindings don’t get ported to 2.x before OH 3 comes out. I’m happy to see the list of such bindings dwindling but there will still be some I’m sure. So the need will be there at some point. My main problem is that I don’t see how what I’ve done in the rules linked to above can be made any simpler for users.
It’s actually already in there. But to create a template you have to basically write the JSON yourself and to import the template you need to use the REST API. Once the template is imported though, you can easily create a Rule from the Template. I think there was some work to publish Rule Templates on the IoT Marketplace but I think the marketplace is going away in OH 3 since it’s an Eclipse service. I’m not sure how they will be managed in OH 3.
As for stuff like Python libraries, I’ve seen mention that the community library contributions to the Helper Libraries might become bundled up as a separately installable binding.
For better and for worse, it doesn’t matter what is in your eyes or in my eyes. Our opinions about what is basic functionality doesn’t matter. All that matters is what someone who is a developer is willing to work on. And the developers will volunteer to work on only those features they see as basic functionality. If we disagree, we can ask for it, which is probably best done as a feature request issue on the correct GitHub repo, or find or become a developer and work on it ourselves.
That would solve one type of use case. But based on past posts from OP and on my own setups, there is a very real need sometimes to run multiple OH instances that providing support in myopenhab.org won’t address. In OP’s case, his main OH instance is physically located in a bad place to put the zwave controller and socat/ser2net was too unreliable. In my case I have an OH instance that is 100 miles away that is largely autonomous but which has some sensors that feed into my main OH instance to drive automations here.
At the end of the day, posts like this on the forum are not very productive. If you want a feature added to OH, you need to file an issue and cross your fingers someone decides to work on it. If you really want a feature added to OH, you need to find or become a developer and submit a PR that implements it.
2 Likes
Markus, I don’t have a zwave problem, the suggestion was in response to recent threads by OTHERS who have problems. Both in response to repeaters and ser2net where many OTHER users have had issues. Read that again Markus. Its not a circumvention at all. Construction these days sometimes renders Zwave less than reliable, maybe your forced to put your controller in a basement yet your home is above? there are so many use cases its not funny. Otherwise ser2net wouldnt even exist!
@Rich, sounds great - looking forward to making it simpler. I havent looked at MQTT 2.5 Event bus because 1.x works for me
Not to get too frustrated, but you asked for a simpler implementation of the MQTT event bus without actually looking at the latest version of the event bus implementation which, in my opinion, is already significantly simpler than the MQTT 1.x event bus and gives you more control as well. In general it’s very frustrating when users ask for things to be implemented which are already being implemented or have been implemented for a long time or even worse, complain about these things. That’s another reason why issues on github are better than threads on the forum. The developers know better than we do what is being worked.
Yes great suggestion, and a place to first develop the idea among others with the same need before creating a bounty. Sadly this forum can not be a new idea friendly place so turning a wish into a solid working proposal can be hard.
Disagree, lets not tie up a dev explaining to a noob why the idea is not practical, better to do that here on the forum. A bug report on GitHub for sure, a well thought out proposal for new feature on GitHub yes, but developing a loose idea into a proposal by someone that does not understand the changes needed to the code is IMHO better done here on the forum.
Very good point. Hopefully after V3 comes out the V1 binding then get moved across as the need then goes up.
1 Like
Disagree, I think 1.x binding with MQTT is significantly simpler than 2.5 with its rules etc.
1 Like
I also disagree, MQTT 2.5 is much more robust than MQTT 1.x
It is really different from MQTT 1.x so without looking into it more, it looks complicated compared to the 1.x, but it is not. And it is much more stable and maintained.