WIP: New Plugin: Miele #357
Conversation
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
Fixed authentication (refresh token needs to be saved again when refreshing access token).
Handled device disconnected.
|
Refer to this link for build results (access rights to CI server needed): |
is identified in the events.
|
Refer to this link for build results (access rights to CI server needed): |
fetzerch
left a comment
fetzerch
left a comment
There was a problem hiding this comment.
Got a chance to test this today with a miele hood. There are a few changes need to get the hood into the device list and to get state updates. I didn't yet try actions yet.
| m_mieleDeviceTypeLabelToThingClassId.insert("coffee system", coffeeMakerThingClassId); | ||
| m_mieleDeviceTypeLabelToThingClassId.insert("tumber dryer", dryerThingClassId); | ||
| m_mieleDeviceTypeLabelToThingClassId.insert("refrigerator", fridgeThingClassId); | ||
| m_mieleDeviceTypeLabelToThingClassId.insert("hood", hoodThingClassId); |
There was a problem hiding this comment.
| m_mieleDeviceTypeLabelToThingClassId.insert("hood", hoodThingClassId); | |
| m_mieleDeviceTypeLabelToThingClassId.insert("cooker hood", hoodThingClassId); |
There was a problem hiding this comment.
I think the problem is different here. Instead of relying on text labels, which are localized, I should use actual IDs.
Not sure what you meant through cooker, but there is no such appliance defined in Miele's API.
There was a problem hiding this comment.
Yes, using ids totally makes sense. The change was needed to get my hood to show up as device. The type sent is "Cooker hood" (not "Hood"). The other device I have is a cook top and that identifies itself with "Hob".
Just note that the type id is not sent in the /short/devices answer. From what I can see, it's only used in the reply to /devices.
I | Miele: Got device: QMap(("details", QVariant(QString, "https://api.mcs3.miele.com/v1/devices/XXX"))("deviceName", QVariant(QString, ""))("fabNumber", QVariant(QString, "XXX"))("state", QVariant(QString, "Off"))("type", QVariant(QString, "Hob")))
I | Miele: Got device: QMap(("details", QVariant(QString, "https://api.mcs3.miele.com/v1/devices/YYY"))("deviceName", QVariant(QString, ""))("fabNumber", QVariant(QString, "YYY"))("state", QVariant(QString, "In use"))("type", QVariant(QString, "Cooker hood")))
There was a problem hiding this comment.
Yes, I will switch to using the /devices request to get the numeric ID. From the logs it seems that the device type as string is not reliable at all (for example, "cooker hood" is not described anywhere in the documentation, and they are also localized - in the logs from /devices/all/events the strings are in German).
miele/miele.cpp
Outdated
| QByteArray rawData = reply->readAll(); | ||
| qCDebug(dcMiele()) << "Raw events data: " << rawData; | ||
| QJsonDocument data = QJsonDocument::fromJson(rawData); | ||
| qCDebug(dcMiele()) << "Got events data: " << data.toJson(); |
There was a problem hiding this comment.
| qCDebug(dcMiele()) << "Got events data: " << data.toJson(); | |
| qCDebug(dcMiele()) << "Got events data: " << data.toJson(QJsonDocument::Compac); |
miele/miele.cpp
Outdated
| while (reply->canReadLine()) { | ||
| QByteArray rawData = reply->readAll(); | ||
| qCDebug(dcMiele()) << "Raw events data: " << rawData; | ||
| QJsonDocument data = QJsonDocument::fromJson(rawData); |
There was a problem hiding this comment.
| QJsonDocument data = QJsonDocument::fromJson(rawData); | |
| rawData = rawData.split('\n')[1].replace("data: ", ""); | |
| QJsonDocument data = QJsonDocument::fromJson(rawData); |
My suggestion is just a quick hack (from https://stackoverflow.com/a/54291477), you might want to implement the server-sent-events protocol properly.
Example data:
event: devices
data: <json>
event: ping
data: ping
There was a problem hiding this comment.
Thanks, I see now where is the problem. I will parse the event raw data similar to how it is done in HomeConnect plugin.
device type. Fixed the parsing of events data.
|
Refer to this link for build results (access rights to CI server needed): |
4 participants
nymea-plugins pull request checklist:
Make sure the pull request's title is of format "Plugin name: Add support for xyz" or "New plugin: Plugin name"
Did you test the changes on hardware, if not (e.g. absence of required hardware), please mention a person to confirm it has been tested.
Did you update the plugin's README.md accordingly?
Did you update translations (
cd builddir && make lupdate)?If you added a new plugin, should it be added to nymea-plugins-all or nymea-plugins-maker?