ImperiHome binding 2.0

@pdegeus Well deserved. Having epic conditions in Colorado this year.

You were right, once inverted started getting the responses I was expecting. Looks like part of the issue is that they would stay with the default until the first time tripped. That’s why they looked ok and then switched to alarm state after being opened the first time.

And yes, nginx worked like a charm so nicely locked down and secure again. Unfortunately made Imperihome think it was a different system so had to rebuild everything but not a big issue.

I’ve been using the binding for a while now and things seem pretty good.

But one strange this I noticed is that when I add a new ImperHome item into my items file, the ImperiHome app (on android) then shows everything as offline, etc. And seems only a stop and start of OH2 will then clear it and the app loads everything again.

Anybody else see that strange behaviour?

I haven’t seen anything like that, @ptmuldoon. If the problem is reproducible, can you post the output of http://your-openhab/imperihome/iss/system and http://your-openhab/imperihome/iss/devices when it occurs? A transcript of the openHAB log when requesting that URLs can also help identifying the issue.

I’m having a small problem with the binding, seems every time I boot OH2 I have to manually restart the binding to make it update imperihome clients (I’ve tried refreshing the clients).

Anyone else seen this?

Oh and thanks for making this binding, it’s made my HA system way easier to manage :slight_smile: :clap:

Just made a discovery for anyone connecting remotely. I had previously setup a reverse proxy for remote connection - http://docs.openhab.org/installation/security.html but was having issues with it the last few days. So in getting ready to trouble shoot I saw the comment in the above doc about how myopenhab.org is operating as a pass through tunnel, so on a whim I setup my Imperihome client to connect to https://home.myopenhab.org/imperihome/iss with my myopenhab login credentials and it worked as a secure connection back to my system.

@pdegeus I wanted to flag this for you since you could add it to the binding documentation.

Hi @lfs_alp5, I’ve seen the same behaviour and am looking into it. There seems to be something wrong with either the openHAB item registry or my code using it. Currently waiting for feedback to decide what the right fix is: Add-on dev: itemAdded called multiple times on RegistryChangeListener at boot

@rgerrans That’s cool! Didn’t know My openHAB was a tunnel for all URLs. I’ll add it to the readme with the fix above :slight_smile:

1 Like

Hi @pdegeus,

First of all thanks for your great work. It made possible for me to upgrade to OH2, as I´m a heavy user of wall mounted tablets. Just wondering if Devshutter is on your roadmap? I use it not only for Shutters but also for volume control per rules, as I don’t like having a switch with my sliders.

Thanks again.

Hi @pdegeus - Id also like to request DevThermostat when you can?

@andredts @greg I think I’ll have some spare time next weekend, will try adding support for those devices :slight_smile:

In the meantime the issue with empty device values is confirmed to be a bug in the Eclipse Smarthome platform. We’ll have to wait for a fix from someone else: https://github.com/eclipse/smarthome/issues/3160. A workaround is to use a single items file, instead of multiple files.

@andredts I’ve added shutter support. Check out a new build on my server (link above). Let me know if it works for you.

@greg The thermostat unfortunately isn’t that easy, I’m still working on that. I don’t have any actual hardware to link to, so I’m not sure about the best way to connect all the different parameters in ImperiHome to openHAB items. IH supports heating (current temp, setpoint 1 & 2), cooling and general, fan and energy modes.
Can you tell me what hardware and items you’d like to use as a thermostat in ImperiHome?

Will test and get back to you. Thanks

@pdegeus

This is the items from my old OH1.8 setup.

/* CanonHeater Via MQTT */
Number	CanonSetPoint "Cannon Setting" 														{ mqtt=">[MyMQTT:mygateway1-in/3/1/1/0/45:command:*:default]",imperihab="room:Dining Room,label:Heater,curmodeid:CanonStatus,currentTempId:CanonTemp,minVal:18,maxVal:28,availableModes:Off-Low-Med-High-VHigh" }
String CanonStatus "Cannon Heater Mode [%s]" 												{ mqtt=">[MyMQTT:mygateway1-in/3/1/1/0/21:command:*:default]" }
Number	CanonTemp 	"Canon Heater Temp [%.1f °C]"	<temperature>	(gEntry)				{ mqtt="<[MyMQTT:mygateway1-out/3/1/1/0/0:state:default]" }

These items are MQTT to a homebuilt MySensors controller for my heater. Sketch is here if you are interested:

So the items:
“Number CanonSetpoint” - this would be Imperihome’s “cursetpoint”

“String CanonStatus” - this would be Imperihome’s “curmode” and it looks like the old 1.8 binding used “availableModes” mapped to Imperihome’s “availablemodes”

“Number CanonTemp” - this is the current temp sent back from the heater, which would map to Imperihome’s “curtemp”

I can understand why this may not be easily implemented… perhaps we can have a look at another heating/cooling devices used in Openhab2, and see what its items are.

@pdegeus
I wonder could you do something like this - which would allow for any “thermostat” like device to work with ISS.

For each item, you would identify it as a DevThermostat , associate it with a particular named thermostat - to allow you to tie them together in your code:
iss:type:DevThermostat,iss:name:BedroomThermostat,iss:param:curmode
iss:type:DevThermostat,iss:name:BedroomThermostat,iss:param:curtemp
iss:type:DevThermostat,iss:name:BedroomThermostat,iss:param:cursetpoint
iss:type:DevThermostat,iss:name:BedroomThermostat,iss:param:step
etc
etc

This way your binding would support whatever is available from the users device to present in Imperihome.

Just finished testing, and it works fine, even better than before, as it get commands UP and DOWN. With OH1.8 add-on commands where 0 and 100, and I had to use rules to get it working. I´m only missing the “link type” Stoppable that adds the STOP button to the interface and STOP command to the Shutter. Using for volume control it´s just perfect.

Thanks a lot.

@greg There’s a new build on my server for you to test :slight_smile:
I’ve chosen to use the ‘link’ tag already available, plus some additional tags especially for the thermostat device.

Support is limited to one setpoint and no fan modes, so you can try it out if that’s enough for you. The readme is not updated yet, here’s an example:

Number Thermos_Setpoint   "Thermostat"        ["iss:room:Test", "iss:type:DevThermostat", "iss:step:0.5", "iss:minVal:15", "iss:maxVal:24", "iss:modes:Home,Away,Comfort,Sleeping", "iss:link:curmode:Thermos_Mode", "iss:link:curtemp:Thermos_Temp"]
Number Thermos_Temp       "Thermos temp"      ["iss:room:Test", "iss:type:DevTemperature"]
String Thermos_Mode       "Thermos mode"      ["iss:room:Test", "iss:type:DevGenericSensor"]

Happy easter!

Thanks for doing this. I tried to test with my Ecobee and got the following error:

2017-04-15 15:50:41.458 [WARN ] [ome.internal.processor.ItemProcessor] - Unit tag is not supported for device AbstractDevice{id='d835c281dece82839a3c4ba664ecdb778aa8f801', name='Desired Temp', room='aa2c3291fd1e605c76750598a849c9b6a31d2f3c', type=THERMOSTAT, invert=false, icon=null, links={curtemp=Thermostat_SF_actualTemp, curmode=Thermostat_SF_desiredComf}}

Now I did add “iss:unit:°F” and changed min/max to 60/80 step 1.0

Edit: Though that said, it does look like the setpoint and current temperature are working.

You’re right, that may be a bit confusing. ImperiHome actually expects the unit on the ‘curtemp’ value and uses it for the setpoint too. You can move the ‘unit’ tag to your current temperature DevTemperature device to make it work.

HI @pdegeus - Looks good! - Ive only had a quick test/play with it, but all seems to be working for my heater.

Thanks heaps!

It looks like after a reboot it went away but pulled it anyways. Thanks.

On another question, do you know what is the best Dev type to use for a security system? When I was running it through my Vera I could set the state of my security system through Imperihome but now that I have it running through OpenHab I wasn’t sure what Dev type to use (was looking at some of the alarm types (like devDoor and then setting the Armable=1 or should I use a devMultiswitch so that I get all the options of Home/Arm(Stay)/Arm(Away)?

I think at this point it should be a smart combination of switches/multiswitches and openHAB rules to arm/disarm the system. You can already use a composite security widget in ImperiHome to group your devices and display the status on the dashboard.

Currently the armable parameter and arm/disarm action are not supported by the binding. I’ve planned to play with this and create my own alarm system for months but you know, always busy with family, daughter, work. I’ll let you guys know when I had the chance :slight_smile: