What I don’t like about current OH community process is people come in here, they say “hey this rule is not working, can you help?”, and then some generous member helps him. But again, next day another 10 users pop out saying, help me too. When will this end? At the same time, its unfair we hope everyone to be good with programming skills. We need to have a way to standardize solutions in terms of re-usable packages.
Microsoft solved it back then in 1990s with diverse set of hardware, thats why they still hold over 80% desktop OS and applications platform market. They created these nice abstractions for programmers.
No matter how different, two houses are, they have to have common things like, heating/cooling system, fans, lights, front door, bedrooms, living rooms, pets, family members, terrace, party. etc. Its our job as platform designers to extract and present these abstractions to programmers. Thats how we get army of devs on our side.
The answer to your question is: “NEVER”. People asking questions, getting their answer, and then others coming back with the same question has nothing to do with the overall OH concept, it has to do with the users’ common sense and in some cases with IQ!
Whatever you may think you can improve with the scope that you are stating is not applicable to the aforementioned users of OH.
Yes, Kotlin is a nice programming language, that might be useful for OH/ESH, but not for the reasons you imply!
A question to you. Have you ever had to write any code, as a user, specific to your android device or iOS device or windows device or linux device? To get the desired behavior. I never had to.
I am of opinion we should not help users writing rules for their specific use cases. Then its “charity”. If you want to do that, it your choice.
But if you really care about the problem here, you will think of some re-usability and that has nothing to with Kotlin, its about standardising abstractions, be it in Java or other langs.
Yes (Cordova, to be specific), because it had to fulfill my specific requirements.
The re-usability you talk about has nothing to do with the users we have here! It is there, at their fingertips!
This is another issue, and deals with templates/patterns! You can not have a fully integrated rule unless you customize! OH is not about “charity”, it is about the old saying: “give a man a fish and you feed him for a day, teach a man to fish and you feed him for a lifetime”.
Just my 2 cents!
I don’t think we are teaching effectively. And we shouldn’t have to repeat our teaching with every new user. Thats a big toll on our experienced members, thanks to their generosity. But this should not go on forever. It will not, because we will all die at some point. What really survives is re-usable code in some baseline project.
Oh, yes we are, @rlkoshak is doing this for a very long time! Myself as a community member tried to do some order (Rich helped a lot), see:
but it did no better!
Hopefully, it will! If you are in to this project, then please help!
Feel free to make patterns, it is helpful to all of us. openHAB project will be online: cloned, or original.
To be clear: I do appreciate your approach in terms of Kotlin based idea!
You both want the same thing: Helping users (and making OH used by more users).
Both ways you are describing can work parallel. User asking questions (even once that were asked several times before) will never stop. People answering those questions will hopefully never stop.
In my opinion: Creating more reusable code is still a very good idea. Even OH has good examples. Take HabPanel and it’s Widget-Gallery or people posting design patterns for rules in the forum.
It won’t stop questions, but it could change the way people use OH in a positive way. It could be a good idea if you want open OH to a broader public.
Friends, I am giving some serious though to my abstractions concept. Imagine something like Linux /dev getting populated based on sysfs info. In our case the ThingTypes in bindings would be like sysfs, we may need to annotate channels with meta-info, that would help categorizing them. e.g If the channel type is Dimmer, I would like to know if its a White Light or Fan or RGB Light or Volume. If that info cannot be derived by binding developer (e.g z-wave binding is very generic, the binding itself doesn’t know the category of device a dimmer is controlling), then there should be a site specific mapping configuration. Specifiable in a very concise manner.
In the end, a developer or even advanced user like Rich would be able to write rule/app against the common abstractions. e.g If there are more than 3 people in the given section of building, change that heat pump settings to xyz. The rule will be written against generic abstractions Person and HeatPump, DeviceLocation and Presence.
A draft spec is in progress. It will be something that presents Items/Things/Channels/SiteConfig in a more meaningful and standardized way to programmers. The API will be available in Kotlin and Java both. I would also want to go one step further, gather our knowledge about all existing bindings and their thing types and create a base mapping layer, which can be overridden if necessary by site admin. Community will keep the base layer as updated as possible.
A strange co-incidence, we both praised the teachers (our senior members), on day of 5 Sept. Its teachers day in India today. I didn’t know this till this moment.
Have you engaged with any of the rest of the OH maintainers? This is very ambitious and will require significant changes to core OH and ESH features. The people who have been here working on OH for years now will have opinions and more importantly the power to decide whether your additions are included or not.
No one in this or the other thread are maintainers. You need to be having these same discussions with them. You need buy in from them. You need their help. Otherwise all this work is for not. Or you are heading down the path towards a fork.
Which is what Items are. But here is the difference. For me zwave:device:dongle:node4:switch_binary is my front room lamp. I create an Item named FrontRoom_Lamp, linked to that Channel and define how it is to behave (its a Switch), how it looks (label and icon), how it is controllable from Alexa or Google Assistant (tags), and its relationship with other Items (Groups). There is nothing intrinsic to zwave:device:dongle:node4:switch_binary that can be used to automatically create these abstractions. And frankly, it is only my front room lamp because that is what I have plugged into it. It could be a garage door opener, a coffee machine, or any number of other binary controllable devices.
We can argue whether Items are complete and creating Items is indeed clunky and should be better, but I think you are vastly underestimating how much of this is appropriate to do automatically, let alone possible to do automatically. OH is not an OS that runs programs, to use the strained metaphore you seem to like, where users run apps. OH is a platform upon which users BUILD their app with the app being their home automation. This is true even of the more limited commercial options like Vera, Wink, and SmartThings.
There is nothing that will change that. Even if you free the users from ever needing to code Rules themselves we will have users coming in and asking “hey this library isn’t working can you help?”.
On just the heating/cooling front I think you vastly underestimate the sheer diversity. We have
central air with one central controller
multi-zone central air
multi-zone central air with controllable vents
ambient heating with a different controller per room
ad hoc heating/cooling (e.g. I don’t have an air conditioner but I do have a house fan and a basement that is cooler than the rest of the house so I run the house fan as if it were an air conditioner)
Except for the fact that they all deal with two or more temperatures there isn’t much overlap there.
And even where there is, there isn’t much overlap between what user A wants to do with his HVAC and what user B wants to do.
If users cannot write rules to address their specific use cases then what exactly is OH for? Users need to be able to define the custom behaviors of their custom home automation system or else this is all pointless. I’ll say it again. OH isn’t an app, it’s a platform for building an app.
That’s not to say we can’t have or don’t need reuse, but if all we provide is reuse then there may as well not be an OH. I wouldn’t use it. The likelihood that someone has coded something that is an exact match for my specific home automation use cases is relatively low.
Have you looked into metadata? It’s not currently accessible through the Rules DSL, but I do not see why this wouldn’t be opened up. I have not yet been successful accessing metadata from JSR223, but I would think this should be possible.
Ganesh (I’ve suspect that’s you returned in another guise for awhile now and this confirms it), if you see this I have one last parting statement for you but I’m mainly posting this for everyone else who comes along with big ideas.
OH is a community project. You have to work with the members of the community and work within the rules and procedures of the community. If you are not willing to work with the members of this community, in particular the maintainers, then you will accomplish nothing.
I fail to understand why a suggestion that you actually work with the members of the community who actually decide what does and does not become part of the baseline is grounds for quitting. But if you would rather quit then actually discuss anything with the people who can actually support your work then you were never going to accomplish anything anyway. Nothing you do can become part of the baseline without their support.
If you want to fork OH or ESH and go build your own please do so. But don’t expect me or anyone else on this forum to support you in that. This isn’t the “Support Ganesh/diyha’s latest grand ideas” forum. If it doesn’t improve OH I’m not interested.
I believe you will be much happier if you just fork OH or ESH and go build your own thing. Then you will have full power to make any changes you want to the baseline unilaterally, since apparently actually working with people is too hard for you.
And in the future, I will trust my intuition and refrain from engaging the next time I suspect you have come back in another guise. I’m sure Kai will delete this account too if you ask.
I do hope that no one will delete your posts, they are definitely a “how not to act inside a community” example.
I do hope though that your rage will disappear, and that you will thoroughly read the feedback you had from this community’s members and reconsider at least the attitude!
You, “my dear”, have been rude!
