First draft for image download from miniserver #197

TCke83 · 2023-02-22T20:19:04Z

@jimirocks i've quicky made a first draft for downloading (and caching) images from the miniserver, could you take a look and give me your comments?

The caching part maybe needs to be more permanent (together with the App object, if the last modified timestamp doesn't change), but that will be another change i guess.

jimirocks · 2023-02-27T17:45:37Z

Hi, thanks for another contribution, will get into that in day or two - hope you are not in a hurry ;-)

TCke83 · 2023-02-27T18:11:43Z

@jimirocks not in a hurry from my point of view. Love the time/effort you guys invested in this library so happy to contribute to make it even more complete. Give me your thought about the implementation.

jimirocks · 2023-03-11T08:42:21Z

@TCke83 Hi Tom, sorry for beeing late. Here are my thoughts on design (and I will also add few notes into the code):

Because there is no way how to pair file request with file response on otherwise async websocket communication, there should be single point for getting APP (calling it APP since there is also FTP interface with lot of other files available) files from Miniserver. Therefore let's rename LoxoneIconRegistry.getIcon to LoxoneAppFiles.getFile
I think this LoxoneAppFiles should be available straight through Loxone class
- add Loxone.appFiles() method
- the LoxoneAppFiles can take LoxoneWebSocket as constructor parameter => there will be no need for CommandRequestResponseListener (which feels weird anyway)
Separate the image/file cache from the LoxoneAppFiles - similarly to TokenRepository introduce simple FileRepository interface and provide it's in memory implemntation for the beginning

Would you agree on this proposal?

jimirocks

Thx for contribution - things need to be adjusted and tried out.

src/main/java/cz/smarteon/loxone/CommandRequestResponseListener.java

src/main/java/cz/smarteon/loxone/message/ImageCommand.java

src/main/java/cz/smarteon/loxone/app/Room.java

jimirocks · 2023-03-11T08:52:21Z

src/main/java/cz/smarteon/loxone/LoxoneWebsocketClient.java

@@ -82,8 +82,16 @@ public void onOpen(final ServerHandshake handshakedata) {
    public void onMessage(final String message) {
        LOG.trace("Incoming message " + message);
        final MessageHeader msgHeader = msgHeaderRef.getAndSet(null);
-        if (msgHeader != null && msgHeader.getKind() != MessageKind.TEXT) {
-            LOG.warn("Got text message but " + msgHeader.getKind() + " has been expected");
+        if (msgHeader != null) {


I am kind of surprised that binary content comes as text? Are you sure this shouldn't be in onMessage(ByteBuffer) method? Or is it like SVG icons come as TEXT and PNG icons as ByteBuffer and both onMessage methods need to be adjusted? Also it's a question whether we should work with possibly TEXT content as binary? Should the registry somehow support both or more possibilities?

Your assumption is correct, when it is a text message it is an SVG file, when it is a png file it is a binary message. Will try with my miniserver to add a png file and test it out to be sure.

jimirocks · 2023-03-11T08:54:15Z

src/main/java/cz/smarteon/loxone/LoxoneWebsocketClient.java

+                ws.processFile(message);
+                return;
+            } else {
+                LOG.warn("Got of wrong type " + msgHeader.getKind() + " has been expected");


before your change it tried to process even unexpected kind of incoming message, please do it the same way (the explicit return won't be needed then)

It seems to me it will still try to process it as a message event if it is not FILE or TEXT, what do you mean exactly?

ahh you are right, but I would prefer to remove explicit returns and put the ws.processMessage into else branch

jimirocks · 2023-03-11T08:57:36Z

src/main/java/cz/smarteon/loxone/LoxoneWebSocket.java

+            final Command<?> command = commands.remove();
+            if (!Void.class.equals(command.getResponseType())) {
+                try {
+                    ByteBuffer byteBuffer = ByteBuffer.wrap(file.getBytes("UTF-8"));


well it's a question why to wrap incoming String to ByteBuffer? It only brings encoding complexity in place

I guess it's possible to know whether it's text (SVG) or binary (PNG) from the imagereference? If yes it could make sense to explicilty set this information in Command and behave according to that

Also the decision could be up to listener (registry) - making Command based on String

I've looked to the documentation and it seems you can download all svg images also as png image, will try to simulate that also on my miniserver.

src/main/java/cz/smarteon/loxone/LoxoneIconRegistry.java

jimirocks · 2023-03-11T09:05:54Z

src/main/java/cz/smarteon/loxone/LoxoneIconRegistry.java

+            iconLatch = new CountDownLatch(1);
+            loxoneWebSocket.sendCommand(ImageCommand.genericControlCommand(iconUuid));
+            try {
+                final int timeout = loxoneWebSocket.getAuthTimeoutSeconds() * loxoneWebSocket.getRetries() + 1;


do not use auth timeout, also no need for any retries?? I would recommend to use very short timeout for this.

What timeout do you suggest? 1 seconde? Also I see no possibility at the moment to send a command without retry, should I add this to the LoxoneWebSocket class?

well sorry, I wasn't very clear. No need to tweak retries.

Let's introduce possibly configurable separate timeout?

Or we can keep it like this for now - the more I am thinking about it I feel it would be better to add some blocking request-response method to LoxoneWebSocket instead... but I need more time to try out....

See #200

Added a timeout for file retrieval with 1 second default timeout

jimirocks · 2023-03-11T09:12:19Z

src/main/java/cz/smarteon/loxone/LoxoneIconRegistry.java

+                if (iconLatch.await(timeout, TimeUnit.SECONDS)) {
+                    return iconMap.get(iconUuid);
+                } else {
+                    LOG.error("Loxone icon wasn't fetched within timeout");


the bad thing here is that if no file is received the command is pending in LoxoneWebsocket creating incosistency there and possibly breaking all the communication - this is not your issue, rather the design issue of the whole library.

Could you please find out what happens when somebody request a file which does not exist? Does miniserver answer anything or just nothing?

I've tried this and found that the miniserver responds with following message:

{"LL": { "control": "IconsFilled/unknown.svg", "value": "Bad request", "Code": "400"}}

This is a message with TEXT format, so picked up by the processMessage(final String message)where it fails to convert the message to the ByteBuffer format specified by the command. I've tried to use LoxoneMessage as response type, but that causes the LoxoneAuth command listener to process the command. This class thinks the current token is invalid and discards this.

Not entirely clear to me if the response type of the command shoud be LoxoneMessage, this is only applicable if the command results in an error. When the file is found it answers with a FILE type command.

thx for trying, I will look closer on that

jimirocks · 2023-05-28T08:20:32Z

Hi, sorry for not being able to progress on this due to other priorities. Is your proposal still relevant?

jimirocks · 2023-08-31T07:43:43Z

Closing due to inactivity

First draft for image download from miniserver

061fc01

jimirocks requested changes Mar 11, 2023

View reviewed changes

jimirocks reviewed Mar 11, 2023

View reviewed changes

jimirocks closed this Aug 31, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First draft for image download from miniserver #197

First draft for image download from miniserver #197

TCke83 commented Feb 22, 2023

jimirocks commented Feb 27, 2023

TCke83 commented Feb 27, 2023

jimirocks commented Mar 11, 2023

jimirocks left a comment

jimirocks Mar 11, 2023

TCke83 Mar 13, 2023

jimirocks Mar 11, 2023

TCke83 Mar 13, 2023

jimirocks Mar 14, 2023

jimirocks Mar 11, 2023

jimirocks Mar 11, 2023

TCke83 Mar 13, 2023

jimirocks Mar 11, 2023

TCke83 Mar 13, 2023

jimirocks Mar 14, 2023 •

edited

Loading

TCke83 Mar 20, 2023

jimirocks Mar 11, 2023

TCke83 Mar 20, 2023

jimirocks Mar 29, 2023

jimirocks commented May 28, 2023

jimirocks commented Aug 31, 2023

First draft for image download from miniserver #197

First draft for image download from miniserver #197

Conversation

TCke83 commented Feb 22, 2023

jimirocks commented Feb 27, 2023

TCke83 commented Feb 27, 2023

jimirocks commented Mar 11, 2023

jimirocks left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jimirocks Mar 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jimirocks commented May 28, 2023

jimirocks commented Aug 31, 2023

jimirocks Mar 14, 2023 •

edited

Loading