konqi / roborock-bridge

Bridge between a local mqtt broker and your roborock vaccuum through the vendor apis
MIT License
5 stars 2 forks source link

Possible regression with org.springframework.boot #80

Open konqi opened 1 month ago

konqi commented 1 month ago

One additional note, that is not directly related to this topic: As I mentioned when using a higher version than "3.2.5" for "org.springframework.boot" I did not get any update for the states. I thought I got it fixed by removing the second parameter when calling publishDeviceStatus(message.deviceId) in "BridgeService.kt" (line 173). Then I did get updates when requesting state updates, but I did not get all properties, just a handfull. I was not able to find out why that's the case, maybe you have an idea (but maybe that should be another topic, because it has nothing to do with this).

Originally posted by @dkneisz in https://github.com/konqi/roborock-bridge/issues/71#issuecomment-2289581727

dkneisz commented 1 month ago

I tested this with your current main branch. When I request as state update, I don't get anything. The log states:

2024-08-16T20:00:19.860+02:00  INFO 1553133 --- [           main] de.konqi.roborockbridge.BridgeService    : Requesting device state refresh via mqtt.
2024-08-16T20:00:19.893+02:00  INFO 1553133 --- [           main] d.k.r.remote.mqtt.RoborockMqtt           : Published 'get_prop' request via topic 'rr/m/i/4EUZXHZXIzF8TWaCO6eXNn/35da0fb1/3nuRxpUimbqlq0IGJdJzGU'.
2024-08-16T20:00:19.992+02:00  INFO 1553133 --- [all: rrb_C0VboI] d.k.r.remote.mqtt.RoborockMqtt           : Lambda: New message for topic 'rr/m/o/4EUZXHZXIzF8TWaCO6eXNn/35da0fb1/3nuRxpUimbqlq0IGJdJzGU' 0
2024-08-16T20:00:19.998+02:00  INFO 1553133 --- [all: rrb_C0VboI] d.k.r.remote.mqtt.MessageDecoder         : Received response to request 11 with method 'GET_PROP'.
2024-08-16T20:00:20.093+02:00  INFO 1553133 --- [           main] de.konqi.roborockbridge.BridgeService    : payload: IpcResponseDps(id=11, result=[Lde.konqi.roborockbridge.remote.mqtt.ipc.response.payload.GetPropGetStatusResponse;@5cf21908, method=GET_PROP)

There is nothing published to any of the state properties. When starting the service (I run the jar as a service on a Debian 12 machine) I get updates on some properties, but not on all (e.g. "is_cleaning" is missing, as are a lot more). When I change line 174 of BridgeService.kt from

publishDeviceStatus(message.deviceId, notifyAboutChangesAfter)

to

publishDeviceStatus(message.deviceId)

I get updates when requesting a state update, but I still don't get all properties. Switching back org.springframewordk.boot back to version 3.2.5 I get all properties when requesting state update.

konqi commented 1 month ago

That could actually be normal. publishDeviceStatus only copies everything from the in-memory store to mqtt – it doesn't request anything new from the robot. The service closes the mqtt connection when the robot is idle and polls updates via rest every couple of minutes, however the rest apis don't provide near as much information as the robot itself via mqtt.

If you want polling via mqtt you can change BridgeService.kt:96 to include IDLE robots. I recommend only trying that for testing. When the robot is active the mqtt polling should automatically kick in.

Edit: Come to think of it. You did mention that you don't use a S8 Ultra, right? In that case you might need to create a copy of the S8UltraInterpreter.kt file and adjust some of the stuff for your robot. You can set a Breakpoint in SchemaValueInterpreter.kt:70 :75 :78 to get the correct value for name and modelNames. That won't fix anything, but you're probably running on the pretty dumb GenericInterpreter 🤪 so values from mqtt and rest might be correctly correlated to each other.

dkneisz commented 1 month ago

I have a Roborock Qrevo Master. I already tried to copy S8UlstraInterperter.kt and set it to my model. This did work, however I don't see any benefits in that. I already have the "raw" values and I can work with them. For my case I use it with openHAB and use map files to get the name for the returned values.

As mentioned, everything is working when using version 3.2.5. I get all properties with their values. If I use anything above that I run into mentioned issues. I noticed this during the robot was cleaning, when the mentioned "in_cleaning" did not update. So I don't think that this is normal. If this was the case I shouldn't get all values when I request a state update in any case when the robot is inactive.

konqi commented 4 weeks ago

This did work, however I don't see any benefits in that. I already have the "raw" values and I can work with them.

REST api and MQTT api provide some of the same values. The Interpreter merges these into a single value and provides them to mqtt as one value. If you don't have an interpreter some of the values will get updated via rest calls, others only via mqtt. Doing the mapping in openhab is possible. However, if you would contribute your interpreter, other people could benefit from your findings and don't have to figure everything out themselves.

I don't use properties like in_cleaning. I only rely on state to determine what the robot is doing. Then again, this needs an interpreter to work properly. It is still weird that changing the spring boot version would make any difference.

There is another mechanism at play here. Only values that differ from the ones in the database are updated/persisted. There could be a bug in that logic as well.