Closed shossk closed 2 years ago
Since I don't own a sharp air purifier it's a bit hard for me to debug and test it
But it should be similar to how I implemented the aircon. Could you maybe dump the box info of your purifier with properties and status as json? (Method is 'queryDevices')
If it's very different maybe we need to differentiate device types by different classes
Thank you! I'll attach the json!
Can you tell just by looking at the json? I think it's the same to some extent, but the temperature and humidity locations are different, and there seems to be more data for PM2.5 and dust.
By the way, the temperature and humidity data seems to be here.
{
"statusCode": "F1",
"valueType": "valueBinary",
"valueSingle": null,
"valueRange": null,
"valueBinary": {
"code": "5200D813300EFF00F00000000001CD00070000000700000485000000000000000000000000000000"
}
}
offset 4 is temperature offset 5 is humidity
I've been working on forking it over here, but it's still hard to separate the classes for air conditioners and air purifiers, so if you can do that, I can test it and submit a pull request.
I can send you the data if you need it.
Could you capture a few requests from the app?
Like link it to something like Proxyman or charles, then open the cocoro app and change a few values in increments.
Since the cocoro class is just interfacing with Device, I think it would make sense to add this as a separate device (https://github.com/dvcrn/cocoro-sdk/blob/master/src/device.ts#L43), maybe a subclass? Since all a Device has to do is prepare the update queue. The Cocoro class is then batching it to the sharp servers
Maybe we can try to subclass/inherit from Device and see what is common, and what is different. (Device -> Aircon, Device -> AirPurifier)
In either way we need to overwrite / redefine a few methods like getRoomTemperature() (https://github.com/dvcrn/cocoro-sdk/blob/master/src/device.ts#L186), etc to read from the different properties
I think subclassing is a good idea too. I'm sure I can help you implement and tweak methods and such once you get to a certain level of subclassing.
The sending part is the same as the method of executeQueuedUpdates, so just send the status part.
Another feature that air conditioners do not have is a part that displays the status of the air. I'd like you to get it for homebridge :)
This is probably it.
# smell
(I have no idea why there are two.)
F2 -> line 30:31
F2 -> line 36:37
# PM2.5
F2 -> line 36:37
Thanks for providing! Looks good
So it's writing mainly to 運転状態詳細3
(F3)
{
"statusName": "運転状態詳細3",
"statusCode": "F3",
"get": true,
"set": true,
"inf": true,
"valueType": "valueBinary",
"valueSingle": null,
"valueRange": null
},
eg: Humidification Off: 000900000000000000000000000000000000000000000000000000 Humidification On: 000900000000000000000000000000FF0000000000000000000000
(Humidification setting is likely 0009, and FF/00 defines state)
It looks simple to implement these actions on first look...
I will see when I can find some time to setup the subclassing, but you can also just do
class Purifier extends Device
and ignore all of the existing methods in Device, and just focus on implementing things specific to your purifier. So we can build a quick WIP to test, and split it properly later
For setting the binary data you can see how I did it with State8 here - https://github.com/dvcrn/cocoro-sdk/blob/master/src/state.ts#L21 and
Thank you for waiting.
I've committed the temporary submodularization.
Sorry for the messy writing style... (I want to be able to write neatly in typescript like you do) I hope you can put it together nicely.
If you have any questions, please let me know.
Hi, thanks for providing a useful sdk.
cocoro also includes an air purifier, and it would be great if you could include an air purifier in the name of Git, is that too much work?
It looks like the TEMPERATURE property names are grouped under "F1" instead of "FA", so I'll have to check the binary again.