OK, that’s helpful to know. The solution for smart plugs is probably to use the discovery function in paperui to find the serial number (or peek at the json if you’re technically inclined) if you want to configure everything with .things files.
For reference that’s the only style of plug they’ve ever sold.
If you requested a free range extender back when they first launched the wiser system, they sent you one of these (or in my case, 2):
To start with they were just dumb range extenders, although the soft button on the side (glowing red in the picture) did activate a relay to toggle the socket on and off, however when the hub firmware was updated to add smart plug support, these plugs magically gained smart functionality (if you remove and re-join them)
Been happy with my wiser system and the binding. Only thing I’ve noticed is openhab (refreshing I’m assuming) does kill trv battery life quickly. Thank god I have rechargeable’s
I’ve had the binding since before I added TRVs to the system. Did you notice a reduction in battery life after you connected to OpenHAB or is the TRV battery life just poor anyway?
In my impression the battery life is poor if the TRV has a poor signal. It seems that if the signal is low or needs to keep reconnecting it uses the battery faster. I have three TRVs at the front of the house which connect to a plug/range extender. This sometimes falls off the network itself and then they are all knocked out. Even with the range extender the signal is weak. My impression is that these are running down faster, I’m changing the batterys at least every 6 months.
Quick question: is it necessary to add the Wiser things manually to expose all of the channels?
I ask because I added the things via PaperUI and then items via files but I do not see any battery voltage channel in PaperUI for the TRVs, only Battery level. Am I missing something?
Just to update everyone, the pull request for this binding had now been merged, so should be available when 2.5.8 comes out. Many thanks to @hilbrand for helping get this over the line.
Is there a way we can apply a schedule to a room from OpenHAB? I’m sure I remember seeing the schedules in some text format (json?) in the past but having recently come back to this binding (great to see its now all sorted and included), they appear to be gone?
Use case is being able to flick a virtual switch to indicate guests staying in a particular room and (among other things) setting the heating schedule as required from the constant 15*C it is on normally.
That’s disappointing and confusing as it could be useful to have the scheduling in the same place as the controlling.
(PS - I love the binding you’ve built and really appreciate the time and effort that you’ve put in)
I’ve just got into MQTT and the MQTT binding allows setting up of “customised channels” where you specify the MQTT topic and the JSONPATH transformation to get out (and in) the value that is required for the channel.
Its weird that this is “allowed” but not your implementation.
You could think about this another way. If you’re programming a schedule to set up a constant 15C, why not just use manual mode to set the 15C constant temperature, and then configure a schedule for when the room is in use. Leave it in manual mode by default, and then turn manual mode off when you do want to use the room. Manual mode settings on a room appear to be restored after away mode being activated and deactivated.
Great suggestion. Been trying to write a rule to turn on the heating in the office when I’m working from home. Now I have manual mode linked to presence detection on the work laptop I can increase the temperature if it’s still too cold.
If I try to change the setpoint for a room from an item it just resets back to the scheduled value after a moment. I can see the commands in the events.log but then it just changes back.
I just updated to 2.5.10, deleted the things, re-added them from PaperUI and it’s the same.
I discovered something that may be a clue, in the PaperUI Thing for each room there are two icons for setpoint, one that says “Set Point” and below it one that says “Dining Set Point” both can be adjusted. The one that says just “Set Point” works correctly and the “Dining Set Point” updates to reflect the value set, oh and the radiator fires up too. The “Dining Set Point” one behaves the same as the item in Basic UI and the IOS App, it updates and then after a moment goes back to the original value.
The other clue is if I go to Configuration>Things>Dining in PaperUI there’s a channel for Set Point (which is where I got the channel for the item) but if I try to unlink it says it unlinked but the icon doesn’t change, if I try to link again I get a 404 error. All my rooms behave the same, not only the Dining room.
If I unlink or link other channels in the Room Thing they all work as expected only Set Point misbehaves like this, well that I’ve found anyway.
So looks to me like the channel is misconfigured or mangled in some way but as it is discovered automatically I can’t see any way to change it.
Help…
Edit: I tried “show more” in the Thing and there isn’t a second Set Point in there waiting to be linked only the one.
I had created items for all the channels I wanted in items/heating.items and this has worked for more than a year, I have data to compare this winter with last.
It seems the problem was caused by my manually created items clashing in some way with ones that PaperUI created, set in simple mode. I didn’t even know PaperUI created items as in simple mode they are hidden.
So now it works, I wanted to turn up the heating in the living room when we sit down to watch TV or a movie so it could be set lower at other times. I now have a scene switch that does all the lights and adjusts the setpoint, adjusts it back at the end all operated by Harmony Hub through Hue emulation.
So the remaining issue is I have >12months of data with the short sensible names I gave my items which I have had to delete as they don’t properly work (can’t change setpoint). Seems I had the automatic items all along so at least I can still graph last year against this.
It’s dificult to see what I did wrong in my text file items as the view in PaperUI is different. I’d really rather have the text file config, it’s so much easier to maintain.
Any ideas how I can debug this? Can anyone post a working setpoint item that I can crib from?
I need to fix this before there’s too big a hole in my data!
Oh and this is what my items looked like in case someone can tell me what I did wrong:
// Number Heating_Lounge_Temp "Lounge Temperature [%.1f C]" { channel="draytonwiser:room:WiserHeat02DC85:lounge:currentTemperature" }
// Number Heating_Lounge_Humidity "Lounge Humidity [%.1f %%]" { channel="draytonwiser:room:WiserHeat02DC85:lounge:currentHumidity" }
// Number Heating_Lounge_SetPoint "Lounge Set Point [%.1f C]" { channel="draytonwiser:room:WiserHeat02DC85:lounge:currentSetPoint" }
If your ‘simple’ items have the same names as the text based items then you’ll need to delete these first before you add the text file (they won’t delete after adding the text file - will just get a conflict error)
Thanks, that makes sense, explains the conflict, looking at the notes for this binding my items are fine, a lot like the example ones.
Currently I switched to using the items that PaperUI created, seems they have been there all along as I can still graph them from last year or more. I tried to use the habpanel widget that someone created and the naming is all wrong to work with the simplemode items. Maybe it’s better to change the habpanel widget to work with the autogenerated items, can’t be that hard.
A friend is just installing a Wiser system and I know he’s going to want me to set up openhab for him, so good to get a better understanding of all this.
So did the text based items not work?
The only thing I can think of is the channel is incorrect if not.
While your getting to grips the best thing is to go to the thing that the item will link to and copy the applicable channel:
Brilliant, thanks.