I’m not sure I’m getting updates from GitHub to my local machine so I’m not on the release of OH 2.2.0 yet, let alone the latest build - so I’m going to be creating a new build from scratch too. If I’m “competing” with myself I’ve no worries with you doing the same 
Basically, using what I’ve learnt so far to do with developing a binding I’m going to have a fresh start to try and get something that works better.
I think I’m making good progress here:
I’ve got autodiscovery all wired up, so once you add your heathub in PaperUI, it will find all the connected rooms, roomstats and iTRVs.
Next up is wiring up the handlers to get basic data into channels.
There doesn’t look like an obvious way to easily detect the heathub, nor access the secret without either packet sniffing, or pinging the /SECRET endpoint in setup mode 
I thought the hub has mDNS? The phone app must find it somehow…
Would you mind sharing your JSON from domain/data? I’m really interested in the room, device, stat and trv sections as I think these change depending on the number of items in your setup or firmware version.
A quick look through your code and already I can see it’s far more professional than my attempt! I’ll see if I can get it to work in my setup
I think, but I’m not sure, that the phone only knows how to connect because it has stored the IP and SECRET (or downloads them from the cloud).
When in setup mode the hub always has the same address, so the app always knows how to connect to that.
I haven’t sniffed any data sent when the hub is in setup mode, so I’m not sure what data is exchanged.
I’ll try and sanitize my output later and get back to you.
Okay, it turns out the hub does have mDNS according to a zeroconf browser on my phone, so I’ll try and implement that discoverer service as well. You’ll still need to add the secret manually though.
Edit:
I’ve just added an mDNS discovery participant which can find the heat hub and add it with an appropriate name (the hostname). You need to edit the thing after creation to add the secret, and then manually trigger the discovery process to find all the attached devices. I need to work out how to automatically trigger discovery when the status of the heat hub changes.
Sorry, I was out last night and didn’t get a chance to try your binding. I’ve looked through the code though and wonder if there’s some lists in my JSON that aren’t in yours because of my room setup.
For example, I have:
The room JSON looks like this:
"Room": [
{
"id": 1,
"OverrideType": "None",
"RoomStatId": 50904,
"ScheduleId": 1,
"Name": "Living Room",
"Mode": "Auto",
"DemandType": "Modulating",
"CalculatedTemperature": 200,
"CurrentSetPoint": 180,
"PercentageDemand": 0,
"ControlOutputState": "Off",
"DisplayedSetPoint": 180
},
{
"id": 2,
"OverrideType": "Manual",
"OverrideTimeoutUnixTime": 1515237414,
"OverrideSetpoint": 215,
"SmartValveIds": [
49196
],
"ScheduleId": 2,
"Name": "Bathroom",
"Mode": "Auto",
"DemandType": "Modulating",
"CalculatedTemperature": 205,
"CurrentSetPoint": 215,
"PercentageDemand": 85,
"ControlOutputState": "On",
"WindowState": "Closed",
"DisplayedSetPoint": 215
},
{
"id": 3,
"SmartValveIds": [
60989
],
"ScheduleId": 3,
"Name": "Bedroom",
"Mode": "Auto",
"DemandType": "Modulating",
"WindowDetectionActive": false,
"CalculatedTemperature": -32768,
"CurrentSetPoint": 160,
"PercentageDemand": 0,
"ControlOutputState": "Off",
"WindowState": "Closed",
"DisplayedSetPoint": 160
}
]
I’ve also just noticed my bedroom iTRV has no signal, that explains the temperature reading of -32768
I have similar looking rooms in my JSON, although I have a roomstat & iTRV in one room.
Tbh I haven’t checked that my boilerplate POJO classes fully map to the JSON objects as for the purposes of discover it didn’t matter too much.
I think the discovery services would find your rooms just fine.
One thing I’m wondering about is actually how should the rooms/stats actually be represented in the OpenHAB Thing paradigm. If a user has already configured their rooms etc in the wiser app, I wonder if there is any need to expose the stats as items as the room is effectively an aggregation of a list of stats + some extra metadata. However if we wanted to completely replace the wiser app then they probably should be exposed so you can map them to rooms etc.
This has kept me thinking too. I’d go for two different types of things, rooms and devices. The room is important because it’s what you get and set the temperature for. The device has system information like battery level and signal strength that is good to know too so I think it warrants keeping it in the binding
Yeah, that’s what I’m leaning towards, although I’m splitting out the device types as they have different properties. I also suspect that if you have range extenders in your system they also appear as devices with other properties (and I’m sure I read somewhere that the hardware in those is actually capable of being a smart plug as well).
I might need to get a range extender. The signal in the master bedroom is poor to none. I might monitor it to see when it is connected and when it’s not.
I’ve also noticed this in my iTRVs. They’re both on the same firmware but one has a mounting orientation and the other doesn’t.
"SmartValve": [
{
"id": 49196,
"SetPoint": 170,
"MeasuredTemperature": 168,
"PercentageDemand": 0,
"WindowState": "Closed"
},
{
"id": 60989,
"MountingOrientation": "Vertical",
"SetPoint": 190,
"MeasuredTemperature": 190,
"PercentageDemand": 42,
"WindowState": "Closed"
}
]
Comparing our JSON response there’s some other optional properties but nothing that we’d want to report on.
Yeah, I see that same MountingOrientation on some of my iTRVs. I may also need a range extender. The TRV in my extension has regularly fallen off the zigbee network, and once got itself into a state where I had to manually re-join it.
Right, I’ve got reading room properties into channels working now:
Edit: The -20.0C setpoint for the “Extension” room is when the schedule is set to “Off”. Not a brilliant screenshot as I seem to have captured it when all the rooms are doing nothing anymore.
I was tempted to re-write that in code so that -20 becomes 0. It’ll look better on the majority of sliders then…
Yeah, I think I’ll probably do that.
I’ve managed to get basic data out of the room stat and the TRVs. Battery status isn’t done yet (and I haven’t added a channel for signal strength yet), but I’ve ignored states like “WindowState” etc as they don’t seem to be implemented yet anyway.
I’ve noticed that the demand percentage between the room and the TRV doesn’t always match, i.e. the room has a non-zero demand when the TRV is “off”.
One thing I’d like to do is try and add some “System” state properties (heating override, hot water override, heathub signal strength, channels calling for heat), but I can’t work out how to add channels to a bridge. The designer complains about the things.xml when I add them, and if I ignore them the handler falls over when initialising the bridge 
Right, I think I now have all the the data I would ever want to read out of the system, with the exception of heating schedules (which includes boost overrides). Next up will be some packet capture to see what the app sends when you change setpoints, trigger a boost, etc.
I keep finding more things to add. I’ve now got the eco mode state and the away mode state and setpoint.
I’ve got a number of packet capture runs that record me changing setpoints, changing between manual and auto mode, switching away and eco modes on and off, and boosting.
I’m going to try and add some channels to the rooms for “Upcoming setpoint” and “Upcoming setpoint time” as well as an “Auto/Boost/Manual” state.
With away mode and eco mode, is it just a different value in the RequestOverride call? I had 2 to set away mode, followed by the temperature.
Have you managed to implement the PATCH method to update the status’ without importing a specific version of the Apache HTTP client?
It looks like away mode is set via the requestoverride call whereas ecomode is set via the ecomodeenabled call.
At the moment I’ve not implemented any write methods in the binding, but I’m using the built in jetty http client which should permit PATCH requests.
I’ve just implemented setpoint override for rooms, and partially implemented manual mode for rooms. I say partially, because the setting part seems to work, but for some reason it currently always ends up with the switch being in the off position even when you’ve just turned it on (the app displays it just fine).
In relation to your earlier comment about PATCH, the jetty client newRequest has an overload that lets you pass a String as a method, in addition to the HttpMethod Enum, so yes, I can use PATCH just fine.
Turns out room manual mode was working, I was just reading the cached state rather than the freshly updated one.
I’ve added eco mode and away mode switches now. The away mode set point appears to be cached in the app, as the API response seems to lose the setpoint when you switch away mode off, so for the moment I hard-code it to 5C, and the setpoint isn’t editable.
The readme now documents all the implemented channels and a few that haven’t like “upcoming setpoint temp and time”, “room boost” and schedules.
