Skip to content

Conversation

@heavyweight87
Copy link

MDT tested with a Vailant heatpump

@DerAndereAndi DerAndereAndi marked this pull request as draft October 15, 2024 16:51
@DerAndereAndi DerAndereAndi added the enhancement New feature or request label Oct 15, 2024
@heavyweight87 heavyweight87 marked this pull request as ready for review October 27, 2024 09:46
@DerAndereAndi
Copy link
Member

DerAndereAndi commented Nov 4, 2024

Thanks a lot for this PR! The changes and additions look good so far. Would it be possible to get a SPINE trace log to see the communication in action? That would be the best source for me to evaluate the actual implementation.

Additionally I started adding comments to the New... methods in all usecases. Would be great if you could add that as well, see #136

@heavyweight87
Copy link
Author

Sure ill try to get these for you
We actually now parse the trace logs and save the json payloads to a file so its easier to debug issues

Any thoughts about adding something like this to the lower comms level? A flag that can be set to allow saving rx/tx packets to a file for logging?

@DerAndereAndi
Copy link
Member

I am not sure I understand your question. Could you elaborate a bit more on that please? (You can also join the Slack channel for such discussions, linked in the enbility.net contact page)

@heavyweight87
Copy link
Author

A feature that would allow saving of the incoming and outgoing packets to a file, for later inspection. It would be great for debugging purposes especially as due to the encryption tcpdump is pretty useless

@DerAndereAndi
Copy link
Member

That's imho already possible by implementing the logging interface and writing that output to a file. See https://github.com/enbility/eebus-go/blob/dev/examples/hems/main.go#L96 and https://github.com/enbility/eebus-go/blob/dev/examples/hems/main.go#L322-L368

@heavyweight87
Copy link
Author

websocketLogs.json

Hi,
I attached a log - we store it in json format so its easier to read

There are other usecases here as well (new ones me and my colleague david opened) so there may be a bit of noise

// possible errors:
// - ErrDataNotAvailable if no such limit is (yet) available
// - and others
Temperature(entity spineapi.EntityRemoteInterface) (float64, error)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the Use Case specification, every reading of a DHW temperature can be in a different state: normal, out of range, erroneous. We have to think about how we can handle this.

// possible errors:
// - ErrDataNotAvailable if no such limit is (yet) available
// - and others
Temperature(entity spineapi.EntityRemoteInterface) (float64, error)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also need to think about how we want to handle different units. According to the UC spec, the measurement can be reported in different units. I talked to Andreas and we said it makes sense to let the user request the temperatures in different units, so this interface needs to be adapted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants