AlainKaim / homebridge-heatzy-as-switch

Homebridge plugin for Heatzy devices, considered as switches
GNU General Public License v3.0
8 stars 6 forks source link

Heatzy Pilot V1 Fail #1

Open Enerv78180 opened 4 years ago

Enerv78180 commented 4 years ago

Hello,

The plugin works well with Heatzy Pilot V2, but it don’t works with V1.

The switch is well created in Apple Home app but when I put the switch on, the status is KO

AlainKaim commented 4 years ago

Hi All my devices are V2, so it will be difficult for me to test and debug this. Can you post the error message you got in homebridge log ?

Enerv78180 commented 4 years ago

Hi,

I understand, I have one V2 and Five v1 😂

Log errors are

[Homebridge] [2/25/2020, 3:45:52 AM] [Alexia] Error : 400 BAD REQUEST [Homebridge] [2/25/2020, 3:45:52 AM] [Alexia] Error - Cannot change state

AlainKaim commented 4 years ago

Thanks. I have read again the Heatzy documentation, and I saw no difference between the V1 and V2, on the functions I am using.... Could you choose the debug option in the config file for one of the V1, and then post here a new log file ?

Enerv78180 commented 4 years ago

Hi Alain,

I launch the plugin with Hoobs. I’m dummy user and I dont know how launch debug mode. Just i have try with jeedom homebridge plugin with the Jeedom Heatzy plugin and transfert to your plugin for homebridge intégration works fine.

I dont understand why in hoobs he’s failed

Maybe v1 and v2 have 2 different ID product who need to be indicate in the code ?

AlainKaim commented 4 years ago

Hi I do not use the "product key" in my code : none of the API functions I am calling needt have this ID as a parameter. I know nothing about Hoobs, so I cannot help with it.

But you must have written somewhere the name, username, password and did of your devices. In the same config file, just add this parameter for at least one of your V1 devices : "trace" : true Restart homebridge, and you will get a log file with more informations, every time this device is accessed.

Enerv78180 commented 4 years ago

Hi Alain,

See below informations for V1 :

[Homebridge] [3/2/2020, 10:17:20 AM] [Margaux] HomeKit changed state to (true for cft, false for eco): null [Homebridge] [3/2/2020, 10:17:20 AM] [Margaux] Error - Cannot change state

NicolasBig commented 4 years ago

Hi Alain,

Thanks for your work,

I observe the same messages on Homebridge HomeKit changed state to (true for cft, false for eco): null Error - Cannot change state

Or

HomeKit asked for state (true for cft, false for eco): false Error : 400 BAD REQUEST

Any ideas?

Thanks

funkyremi commented 4 years ago

From the documentation, the state sent should be like this:

- “mode”:0 = comfort mode
- “mode”:1 = eco mode
- “mode”:2 = anti frost mode
- “mode”:3 = off mode

And looking into the the code, the state sent is: "eco" or "cft"

AlainKaim commented 4 years ago

Hi. I do no understand your question, if it is one. AFAIK, there is no HomeKit device for heaters with four states. So the whole idea of my développent is to take in charge only the most used states of Heatzy : comfort and eco mode. In my life, when I want to turn off a heater (during summer months), I just use the hard button on the device itself. And I never use anti frost mode. I hope this help.

funkyremi commented 3 years ago

Hello, I pasted the accepted values from the API documentation. This is how I fixed this issue (400 bad request). Replacing "eco" by 1 and "cft" by 0. Also a possible improvement could be to let the user decide what state to use for on and off in the settings.

AlainKaim commented 3 years ago

When I will have some free time, I will update my code.

Sent with GitHawk

AlainKaim commented 3 years ago

I have done some checks, confirmed with my own V2 devices. Fo v2 or V3 devices, the latest (spring 2020) API specify to use numerical values to control the devices (0 for confort, ..), as quoted by @funkyremi . But at least for my devices, the old specification with letters ("cft", ...) still works. For V1 devices, another format is required (“raw”:[1,1,0] ). But I cannot test it myself. When I will have some time, i will change my code to take in charge all of this.

(What is odd is that when the API returns the status of a device , it always returns "cft", ... values)