After getting 2.5.3 running, I was going in try out some new (for me) bindings. The ecobee listed in PaperUI is the 1.14.0 version, and the help for that says it is obsolete. It looks to me like the 2.x binding is very new, and so isn’t in 2.5.3. So I’m wondering the status. How many people are using it? I’m trying to decide to use the 1.x version, presumably stable, but will have to convert it at some point in the future. I’d rather use the 2.x version to avoid that, so how tested is it? When is 2.5.4 planned and will this be in it? Is there a way to install the new version without moving the entire install to a non-stable release? (Is a .jar file the only way?)
I was also looking at the pushover binding. I see in Github, movement from v1 to v3. Can I assume there will be no 2.x version of the binding?
There are only a few people running the OH2 Ecobee binding. I’ve been running it for a couple months now on the two thermostats in my home. It’s been running very well for me. And if it wasn’t working well, I’d fix it.
The PR was just merged, so it will be in the 2.5.4 release. I don’t know the exact timing for 2.5.4, but I would expect it to be pretty soon.
One thing to keep in mind. The OH2 version is not completely backwards compatible with the OH1 version. So, if you start with the OH1 version, there will be some work to switch over to the OH2 version. The changes are not that big (some channels and actions are a little different), so migration is not that big of a deal. Nonetheless, it’s something to be aware of.
I am working on the migration. I am not sure if I will find the time to finalize it and it will be reviewed/approved before OH3 is ready. But there might be a small chance to have it ported to OH2.5.x. Nonetheless the 1.x version of Pushover is running nicely in OH2.5.x.
We will probably release 2.5.4 today (in the next 24 hours).
Thank you both for responding, and for your work on these bindings. I got 2.5.4 installed and some basic pushover set up, and now that I know I can use ecobee v2 I’ll dig into the document next.
Mark,
I see the first thing I need for ecobee is to provide an API key. The help does not say how to get this, and logging into my ecobee account, I can see where to enter the PIN code but not how to get a key value.
In the meantime, on your Ecobee portal home page, click the little menu icon in the upper right, then select Developer from the menu. Click Create New to set it up. Enter an Application Name (put in whatever you want), then make sure to set the Authorization Method to Ecobee PIN.
Yeah, from the v1 documentation, that’s what you need to do. Sorry about that. When I was writing the v2 README, I must’ve missed that when I was going through the v1 doc.
Ok. So you have to make up a unique company name for it. “No Company” already exists And “put whatever you want” doesn’t quite fly–the application name needs to be unique also.
I guess I’m not sure what the openHAB philosophy is. Writing rules is development of sorts, but being a “company” is a bit strange. With the movement to Paper UI, it should probably have the binding as the application, and have it do the web interface with ecobee to get the API key for the user. Maybe that’s bonus points for the 3.0 version.
Christoph,
I’ve been using the pushover, and just have a couple questions. It doesn’t appear to give a status back if it failed, so wondering if you retry it automatically if it gives the 500 response. And do you follow their suggestions to be friendly to their API (https://pushover.net/api#friendly)? Just wondering if I have to implement a “gate keeper” to not send multiple messages close together.
Thanks,
Paul
If you are talking about the OH1 Pushover Action I can tell you it behaves “friendly”. IIRC every method returns true / false to show if the delivery of the message was successful or not. It does not retry on 500, but will log a warning - same for other states than 200.
To be honest I personally do not think a gatekeeper is worth the effort at all. I am using the Pushover API for nearly three years and cannot remember a situation where I really missed a message. Maybe send an email on failure. But it is up to you.
The gatekeeper probably isn’t much more work than centralizing it anyway. I don’t want a sendPushoverMessage in a whole bunch of places, so if I ever have to change the service it’s just one place. So I could check a return value for sendPushoverMessage, but I think all I could do is log it, so if you log it on the error that would make a false return value, then I probably don’t need to do that.
Thanks,
Paul
And “put whatever you want” doesn’t quite fly–the application name needs to be unique also.