Hmm…is there a bug in sending targetTemperature to a heater not connected to a room?
canChangeTemp seems to be false, so the item does not show up in PaperUI, and you will be prevented to send the command.
I am a total newbie - but is this really related to if there is a holiday-program present, or is this a bug?
{code}
public Heater(final DeviceDTO dto) {
…
canChangeTemp = dto.holiday;
…
{code}
commons-codec is already present in openhab - it should not be necessary to add it separately:
241 │ Active │ 80 │ 1.10.0 │ Apache Commons Codec
Assuming you are running 2.5.2:
Still not working? Please add some logs and I will try to help you debug the issue.
Regards
Version 2.5.2 fixed the problem with Commons Codec, @seime
The question about canChangeTemp = dto.holiday was found in version 2.5.2. Is this a bug, or what am I missing?
Regards
The API is undocumented and works by reverse engineering Android code. The initial code base is a port of pymill, and by reading through the code again I found the reason why it was implemented as it is (but possibly I got it wrong):
https://github.com/Danielhiversen/pymill/blob/25e4609e247af17ff3c977d2311742c39ad90fdc/mill/init.py#L502 (copy full url)
There does indeed seem to be a bug for heaters not connected to a room, but I am unable to verify at the moment. Did you try to correct it?
Regards
My first test was to just change the constructor in Heater:
- canChangeTemp = dto.holiday;
+ canChangeTemp = dto.canChangeTemp;
…and put the jar in /usr/share/openhab2/addons. That did not work.
I have not yet debugged it, and I am not familiar with the codebase. Anyhow -
I might be able to have a closer look at this.
Regards,
Any luck?
No, I have not had the time to look at it.
Beeing totally new to this, I forked the addons-project, and put my changes to this binding in /usr/share/openhab2/addons:
[22:10:57] openhabian@openhab:/usr/share/openhab2/addons$ ls -1
org.openhab.binding.millheat-2.5.3-SNAPSHOT-sources.jar
README
After altering the log level through the console, I still can not se that my version is the one running. Checking in the console - the “old” binding is still the one running.
openhab> feature:list | grep mill
openhab-binding-millheat │ 2.5.2 │ x │ Started │ openhab-addons-2.5.2 │ Millheat Binding
Blockquote
So what am missing here??
Newbie - I used the wrong jar-file witch only contains sources :
org.openhab.binding.millheat-2.5.3-SNAPSHOT-sources.jar
Of course I assumed that they also included sources, a slightly different thing 
@seime : I might have a hint at what is wrong, but I have not been able to test it because of the above. Anyhow - the SetDeviceTempResponse class is unused, witch I find strange.
bundles/org.openhab.binding.millheat/src/main/java/org/openhab/binding/millheat/internal/handler/MillheatAccountHandler.java:424
final SetDeviceTempRequest req = new SetDeviceTempRequest(heater, setTemp, masterOnOff, fanActive);
try {
sendLoggedInRequest(req, SetRoomTempResponse.class);
Here we send SetDeviceTempRequest but is asking for a SetRoomTempResponse as response.
also - I logged the canChangeTemp comming back, and for an indivitual heater it is set to ‘1’ (true):
}
2020-03-07 22:18:54.090 [DEBUG] [llheat.internal.client.RequestLogger] - Response home-125
home-125 < HTTP/1.1 200 OK
home-125 < Content-Length: 370
home-125 < Content-Type: application/x-zc-object
home-125 < Server: Jetty(9.1.5.v20140505)
home-125 < X-Zc-Msg-Name: X-Zc-Ack
home-125 < X-Zc-Trace-Id: 9b416eba40c1587e80a68c22ab111be0
home-125 < Date: Sat, 07 Mar 2020 21:18:54 GMT
{
"deviceInfo": [
{
"fanStatusShow": 0,
"manualControlTime": 0,
"isManualControl": 0,
"isHoliday": 0,
"description": "",
"canChangeTemp": 1,
"holidayTemp": 18,
"deviceId": <device id>,
"deviceName": "ff_livingroom_k",
"roomId": <my room>,
"deviceStatus": 0,
"timer": "",
"heaterFlag": 0,
"powerStatus": 1,
"times": "",
"fanStatus": 0,
"subDomainId": 5316,
"coolingStatus": 0,
"currentTemp": 18.0,
"open": 0
}
]
}
“holidayTemp”: 18 seems to be the value that the oven in aiming for (targetTemperature)
Hi Stian,
thanks for testing!
The SetRoomTempResponse parsing does not matter as the response in fact isn’t used at the moment.
I have however built a new version with the canChangeTemp fix. Feel free to test: https://github.com/seime/openhab2-addons/releases/tag/2.5.3-SNAPSHOT
Regarding your last post; the published API has less functionality than the reverse engineered one, so I decided not to rely on it.
Regards
Arne
Hi!
I just got myself two Mill heaters and started testing this binding. As I want to have full control over the heaters I defined them as independent heaters.
Initially, the control via openhab seem to work fine. However after toggling the ON/OFF state and the temperature for a few times I get the an error “‘millheat:heater:home:xxx’ changed from ONLINE to OFFLINE (CONFIGURATION_ERROR)”. Based on the channels available, OpenHab thinks the device is not an indepedent device anymore (masterswitch is gone). The only way I could fix this was by removing all from openhab, remove device from Mill app and start all over.
Has anyone tried indepenent devices before? Is there some additional logging that can be enabled to debug?
Thanks!
Best regards,
Bart
Hi, you can set the log level to DEBUG for the binding (org.openhab.binding.millheat).
I am curious whether the Millheat app shows the desired state after the toggling?
Cheers,
Hi,
The on/off toggling (using masterswitch) works fine. When trying to change the target temperature, it does propagate but only once (or a few times if I remember well from previous experiments). When a fail occurs, the device goes offline in openhab and the logfile states:
2020-10-03 11:36:40.091 [DEBUG] [ternal.handler.MillheatHeaterHandler] - Heater millheat:heater:home:xxx is neither connected to a room nor marked as standalone. Someting is wrong, heater data: Heater [room=null, id=173653, name=xxx, macAddress=null, heatingActive=false, canChangeTemp=false, subDomain=5316, currentTemp=21, targetTemp=19, fanActive=false, powerStatus=false, windowOpen=false]
After the error, the heater cannot properly be controlled via the Mill app anymore. A temp change via the Mill app is immediately overwritten by the last temp that was set by openhab (actually it oscillates a few times between the temp set via the Mill app and the last temp send via OpenHab)
Openhab logfile keeps repeating:
2020-10-03 11:48:43.895 [hingStatusInfoChangedEvent] - ‘millheat:heater:home:keukenheatR’ changed from OFFLINE (CONFIGURATION_ERROR) to ONLINE
2020-10-03 11:48:43.901 [hingStatusInfoChangedEvent] - ‘millheat:heater:home:keukenheatR’ changed from ONLINE to OFFLINE (CONFIGURATION_ERROR)
Are you able to reproduce this by only using the app? I’am trying to determine if it is a bug in the backend service or if the binding is using the API in an uintended matter (the API is undocumented).
Hi all and Happy New Year,
I’m in the process of replacing my 35 year old wall mounted panel heaters. The Millheat wifi serie looks very interesting and since I’m running openHAB 2.5.9 I would love to add 2 heaters to this system. BUT, the posts under this topic gives me the feeling that the OH Millheat addon may not be 100% ready yet. Right or wrong?
I just need to set the temperature for the two panels, so if anyone feels like sharing a few lines of code that can point me in the right direction, it would be much apprecieated? My current system is running Z-Wave only (no wifi yet).
The integration does appear to be broken atm, my intention is to try to resolve whatever the problem is. I noticed that they did a major update on the app some time ago, but did not check further.
(my house is under renovation so the smart home monitoring is close to none-existing for the time being).
Regards Arne
Thanks,
Just a quick one:
When you refere to “the app” is that the OH add-on or a phone app?
Take care.
Yes, the mobile app.
Regards
Sorry, one more question:
Do you know anything about the OH Millheat add-on? That’s what I will need. Is it working OK?
Would be nice to know before I buy the panels.