-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating an SVG element (via input node) is not persistent #55
Comments
Hi Maarten, |
Hi Maarten, My stance on this is that it can be achieved in node-red already & is far easier than making the node remember all state. I'm not saying no at this time but unless myself or Bart have a lightbulb moment, it isnt going to happen soon. In the mean time... If Bart or I come up with something, we will feedback. |
Thank you for your answers. The only thing to do is give each msg that wants to change the SVG a msg.id. All input to the SVG node goes first through this function node: An ui control node triggers every reload of the dashboard and activates this function node, which is linked to the SVG node: I hope this code will help others to 'save the state of the SVG'. |
Hey Maarten,
Thanks a lot for sharing your solution! So you record all messages, and
replay them afterwards. Clever! Although I'm wondering how long you keep
remembering and replaying messages?
We had another proposal last week on the forum:
https://discourse.nodered.org/t/ui-svg-attributevalue-of-an-attributename/24445/11?u=bartbutenaers
Although I proposed that to solve another feature request, we could also
use it 'perhaps' for your issue. Because if the SVG node had a DOM tree at
server side, we could send that DOM tree content to the client side when
needed. But of course it wouldn't survive system reboots.
Just wondering: what do you do at reboot? Is your message list in the flow
memory persistent perhaps?
And it is also not clear to me why users need to store somehow the current
state of their svg... I thought you guys would use it like this: you read
your sensors or other data sources, and then you update the svg to
visualize that state. And a deploy or reboot you again read the current
status of all those data sources again, and you send those again to the
SVG...
But surely I have forgotten some use cases where this isn't possible.
Could you please explain me with a simple use case why it cannot be done
like that?
Thanks a lot for this constructive discussion, which may help lots of other
users!
Bart
|
Hi Bart My use case: I will stick with my solution since it works, but a server side DOM looks like a great solution! On reboot, the SVG image resets again indeed. But as this does not happen that often, it is not a big problem for me. Thanks for your reply and keep up the good work! |
Just for reference, as this was the first thread talking about the issue when I was looking on how to get my floorplan be up-to-date when opening the dashboard: All inputs to SVG go through the replay function node and must have a top level property "id" (alpha-numeric only, only additional character allowed right now is underscore, can easily be changed in the regex in the node). The ReplayOnConnect node needs to know the dashboard tab the SVG is on and will then issue the replay whenever that tab is opened. |
Hi @Alloc86, |
Alloc86 had a wonderful solution to the SVG not keeping content after tab chaging. |
Hello, unfortunately I have the problem with SVG. The values are not saved when I describe it with this function: `var temperature = msg.payload; return msg; Warn: and {"elementId":"Pumpe_ON","selector":"#Pumpe_ON","event":{"type":"click","pageX":354,"pageY":258,"screenX":354,"screenY":342,"clientX":354,"clientY":258,"svgX":-242,"svgY":67,"bbox":[338,265,380,222]},"payload":[{"command":"update_text","selector":"#Betriebsart","textContent":"AUTO"}],"_msgid":"e2b239a5d8d23b99","socketid":"MzQZHxDyjvDs21TqAAAh"}` |
I assume you are talking about my code from #55 (comment) ? |
That's exactly how it is! Unfortunately, I have no idea how to integrate it into this function. I'm just a copier and a Google searcher |
I can't find it, does anyone have an example or a link where it is described, please |
One example from my setup of a function node that feeds the data:
As it's really specific to your setup and use case this won't be anything you'd copy paste but shows how such a message can be set up. |
Hello, Thank you for asking. I tried to keep it small here, to understand the result it had to be this big. For you professionals it will probably be amateurish, but I'll try what I can and get what I can from Google .-) |
I get this when I import your flow: You can't expect me to install all your dependencies, and spend my time to figure out how all your flows work. |
I won't even try
|
@Alloc86, I have done this:
Do you have any idea where this Thanks!! |
Hello, yes the slider in the dashboard is now saved but the value in the svg is not. |
Could anyone help with this please Does my example work for you? |
Your flow above did not set an id, so we got an error in the DataReplayStore Function node. |
Hi,
|
Hi @ninaaa11, It doesn't happen, but I have to admit I can't get it working. The replayed message looks very good to me: it has the correct socketId, has the correct id, has the correct payload. Then the dashboard framework passes it to socket.io but it never arrives at the client. I have no clue how this can happen... |
I got a short moment of illumination... When you refresh your browser screen, a new client session is started. As a result the Node-RED dashboard framework will start a new The replayed message contains the old socket id, so when you resend it then socket.io has no idea what to do with the message. Because the client session for that old obsolete socketId is not active anymore, the message will be ignored. The fix was simply to copy the socket id from the input message (i.e. the 'connect' message arriving from the ui-control node) to the replayed message: Hopefully this flow works better for you:
|
Thank you I tried your example and from the looks of it it is only applicable specifically to this example and cannot be reproduced. At least not without further programming
|
@ninaaa11, I will give you some detailed explanation, which hopefully helps you a bit during troubleshooting...
What I have done tonight, is simply delaying the messages before resending them:
So I only send the messages after 500 milliseconds (= 0.5 second). Then it works fine for me. If I set a very small delay value (near to 0) then it fails, and when I set a larger value (e.g. 1 second) then you will clearly see the delay in your drawing (which is annoying). Here is your flow updated with the delayed message sending:
|
@bartbutenaers Regarding the server history, that sounds good, but I have no idea how to set it up. I'll read through it and let you know if necessary. Thanks so much |
@ninaaa11, Yes indeed it is better to remove the warning from the function node, because in fact it is pretty normal if you arrive in that part of the code... About the 'server history'. Not entirely sure what you mean. Do you mean the socket's I was talking about? If so I was just 'trying' to explain what went wrong. But if the flow should work for you, you can ignore my explanation. It was simply to give you some detailed insight, so you might do troubleshooting easier yourself afterwards... |
The example to update an SVG element through the input node (described here ) works good. But when I reload the node-red dashboard some time later, the SVG image resets to the default one (without the changes).
Is there any possibility to make these updates persistent?
The text was updated successfully, but these errors were encountered: