I have been using openremote for sometime now and now switching to openhab due to frequent downtime on the designer and lack of response from support community. However i have few questions before i full devote to openhab and give up openremote.
Q1 ) Openremote allows https access to execute any created command by associating it to a button and calling the button id via a http command … this is particularly useful when i execute commands on Openremote from my vera scenes - is something similar available on openhab ? Can I run a channel via http command from another system ?
Q2) Scenes in openremote are very powerful as we can do nesting of scenes - are the scenes in openhab equally easy and powerful ?
Q3) openremote allows a in-memory command to store status of those switches which doesn allow status query (lightwaverf) - does openhab provide something similar ?
I’m not very familiar with OpenRemote, so hopefully I’ve understood you correctly.
If you can do a POST request you can change the state of any item in openHAB1 or openHAB2, there are ways of setting the state of an item simply through the URL, but since this goes against the RESTful design it’s best to try getting a post request sorted first.
I do know that the syntax of the rule engine for OpenRemote and OpenHAB are similar. See here for some examples.
In openHAB the current state of any item is saved, in a rule this is obtained with Item_Name.status This can be persisted through power loss by saving changes to a persistence service in openHAB 1.x or openHAB 2.
OH has a full REST API that allows one to query for and modify the state of any Item via HTTP commands. There is also a MiOS binding which allows more direct communication between OH and Vera.
OH doesn’t really have a concept of scenes or nesting. Not knowing Openremote’s implementation of scenes I’m hesitant to comment about this. This may be something OH does as well, it may be something you can achieve in a different way (most likely), or it may be something OH doesn’t do at all and you will have to work in a different paradigm. I would have to understand what “scenes” mean in the Openremote context.
I can say that there is very little that cannot be done in OH. But there are something that require users, particularly those with prior coding experience, to think a little differently about how to structure their rules.
Talking OH 2, it works slightly different in OH 1:
Devices, APIs, MQTT destinations, etc. are all represented inside of OH 2 as a Thing. The Thing contains the stuff necessary for OH to understand how to communicate with the device. Each Thing will have one or more Channels. A Channel represents one or more ways to communicate with that device. For example, a Dimmer Switch may have a Binary Switch channel and a Dimmer channel whereas a Multisensor may have a Temperature Channel and a Humidity Channel and a PIR Channel.
These Channels get mapped to Items. Items are what OH operates on. Rules, Sitemaps, Persistence, etc., all of it only works with and knows about Items. This layer of abstraction between devices and OH is what allows it to be so powerful as hub and what lets it support so many different technologies seamlessly.
Items have a state and this state represents the status of that Item. To be more precise, it represents the most recent reported state of that Item. This state remains in memory and, if persistence is configured, actually gets preserved across reboots of OH.
How this state is kept up to date for devices that can be queried differs from technology to technology but often a polling period is set up or there is a query when OH first starts up and then whenever the device state is changed outside of OH the device reports that change to OH. For devices that cannot be queried, the last reported state is assumed to be its current state.
From your questions it does appear that Openremote works somewhat differently from OH. You will likely have to unlearn/relearn some concepts and ways of doing things. But OH is a big community with lots of support and active ongoing development. I do not think you will be sorry for switching.
