-
Notifications
You must be signed in to change notification settings - Fork 70
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
The result of editing a VIS view or widget is not shown when this view is opened in 8082/vis/index.html -> "No Connection" / "Verbindungsfehler" #510
Comments
p.s.: I just tried to enter "cmd-s" for save (never did that before and never had to do that before, just for testing purposes here and now) and get this message back: @GermanBluefox: Anyone able to support this issue? |
same to me. I get this error after upgrade my container from Buanet version 5 to version 7 (node v16.15.1, npm 8.11.0, jscontroller |
this was the right hint for me: |
This hint does not help me at all. @GermanBluefox: Anyone able to support this issue? Anyone please can help with this issue? |
I can't find the entry here that Catellanus posted, but I got the email notification from him as follows: Castellanus notifications@github.com Same problem here! Node.js: v16.15.1 |
...so PLEEEEEASE can anyone be so kind and assign this issue to someone responsible asap? May be before Christmas? |
@MichaelSchaaf999 there is only one Person responsible for it, it's me |
Thanks a lot GermanBluefox. |
Has the problem been fixed? Got the same error. |
@Alex18081 : No, this issue has not yet even been assigned to @GermanBluefox, it has not yet been fixed. |
ok, thanks |
@MichaelSchaaf999 Assigned for your happeiness (not that it changes anything when the developer will have time to check it - especially because Bluefox already stated that he saw the topic) |
No, the assignment is just the first normal reaction following an issue that has been opened: This does not make me and other users suffering from this weird behaviour happy, to be honest. Happiness: This will come all over us as soon as the issue will have been fixed. Well, we are not talking about a nice-to-have-feature here that for sure has no high priority. For a couple of users the VIS system is totally unusable, no changes and no enhancements possible. More to come, some might not even have noticed this. What can we do to improve this process? Come to Karlsruhe and provide fresh coffee and or donuts? Or sign yet another service contract? Or pay the developer? Or migrate to Jarvis or Node-Red ior iQontrol or what is available in this world? |
Do we really start such discussions now? Ok, here is my (completely personal!!) response to this (and we are 1000% offtopic for the issue) 1.) The developer decides which process he will do on GitHub. Especially for projects like vis which is currently mainly maintained by ONE developer assigning or labeling the issue will not lead to a bit transparency regarding the issue opener, but will not help in anything processwise for the developer beside "effort". So the reality is that the majority of "one developer adapters" will not use assignments to themself ... so yes you can "expect" this ... most likely your expectation will not be fullfilled 2.) Vis has >39k installations and the version you refer to is currently used by > 23k users on their systems. And here I see 3 users posting about an issue This leads me to I will not give any comment to the sarcastic questions at the end of your post because i think this is a totally wrong direction for any constructive working together style |
Confirmed: We are off topic. I'd say: 3000% off topic. Alert: Make myself a mental note - try to strictly avoid one-developer-adapters. What if this dev is hit by a train? Confirmed: Stop developing plans for projects with VIS immediately. |
Hm ...very interesting conclusions. So I need to (sorry) add some comments on them: I think you still did not understand the whole topic ... "one developer maintaining the adapter" means that in a normal case mainly one developer maintains and develop this adapter" and this is true (if you like to hear it or not) for 99,x% of the adapters. So if you do what you said you might can not do anything with your ioBroker anymore. But glad we are an open source project, so this is not really that much of an issue in reality because the source code is publicly available. In such community driven projects several developers work together and alsocode is added by others (as you can see in the PullRequests here). And yes we make sure that for any adapter in the ioBroker Repo we can move over the development to an other developer and still publish new version if the main developer gets hit by bus or do not have time anymore. Furthermore please also consider that you decided to use an Community driven Open Source project where you pay nothing (!!) for this great software and the whole ioBroker system you use (excluding services that you might have purchased). So you should also have a role as Community member/user - and this is potentially to use a bit of your time to also support the developer - or you need to wait until he finds time. Please read your text above again ... is that really honestly your expectations? You "can not check around in your system"? In fact yes you can! But you expect that the developer does that without having the issue in a first place at all ... Does that make sense? The same for that you tell that downgrades are no options? Indeed they are - unless you need the features in one of these last versions. So I take for me that it is not about "can not", but a clear "do not want to", so you limit yourself in finding workarounds and maybe get an working environment ... Ok that's completely your decision. Honestly as my personal opinion: If you want to have SLAs or a premium support (this includes that the develoepr makes sure that all throusand of possible hardware, OS, platforms and adapterversion combinations work together and such) then you should consider an alternative system, where you can buy such support or pay money that you can (try to) tell the company that they must fix your issues. maybe this fits more to your expectations. But coming back now to the initial question and maybe ways to find sources of the issue: Please add the following relevant information in order to allow the developer to have a chance to help you.
|
6.1.11
4.0.23
socket.io 6.1.7
Browser console... mmmhhh... this is Star Trek for me "to explore foreign galaxies", but I try. This is an excerpt from a lot of lines there, but with some red lines (i.e. errors): [Log] Error: 39 - @http://192.168.178.201:8082/lib/js/socket.io.js:6:13962 (conn.js, line 1256) |
That ws is not listed as instance is completely ok if you do not need it as a "webserver" ...all good here |
All good. not shown because you use the integrated socket.io ... YOu can try to untick that button in eb config and then select socket.io.0 and Try if this fixes your issue. Would be interesting to know.
|
No a "hard reload" in browser should be enough to see if there is any change. Is there anything in the ioBroker log when this issue happens? |
These two lines, immediately after the ConnectionError showed: socketio.0 | 2022-07-08 19:14:36.973 | info | ==> Connected system.user.admin from ::ffff:192.168.178.48 And, yes, can be shown repeatedly. Dot48 is the Mac where this runs in Safari. Dot218 is an AppleTablet where a kiosk runs that calls the system too. |
Hallo! Viele Grüße P.S.: Folgendes zeigt mein Log: web.0 | 2022-07-09 13:26:13.190 | info | <== Disconnect system.user.admin from ::ffff:192.168.188.170 vis.0 |
na guck, @Apollon77 , die Einschläge kommen näher. Ein weiterer Me-Too. Vielleicht erst die Spitze des Eisbergs. |
@lhoem Welche versionen waren es vor dem update? Was danach? |
@MichaelSchaaf999 Dadurc das Du das setting jederzeit direkt wieder zurückändern kannst ... low risk ... |
Geändert wie vorgeschlagen. Danke! Woran lag‘s? |
Das wird @GermanBluefox dann noch rausfinden müssen |
Ich schließe mich an - gleicher Fehler (ReadOnly VIS), selbe "Lösung". Danke...! |
Meine Geschichte ist im Forum. https://forum.iobroker.net/topic/55874/gel%C3%B6st-vis-kann-nicht-ge%C3%A4ndert-werden-verbindungsfehler Von der latest bis stable Installation hatte ich alles durch bis das umstellen des WS geholfen hat. |
Danke für die Info, @Brainbug01, den Thread hatte ich gefunden, aber sogleich bei der Textstelle "heute ca 10 Neuinstallationen..." wieder verlassen. Sorry: Mein Gedanke war gleich "das muss doch professioneller aufzuklären sein als durch ständiges Neuinstallieren und Probieren". Open Source Project her oder hin: Aber dass Anwender da durch Herumspielen Lösungen suchen und finden müssen, ist nicht mein Verständnis von Open Source. |
Hallo zusammen, Auch da ist die Rede von der Erstellung eines Issues, aber ich finde nirgendwo ein passendes. Es geht mir nur darum, ob an der Sache gearbeitet wird oder nicht. Viele Grüße, |
Ja Sie ist bekannt und es wird daran gearbeitet - Bluefox ist aktuell aber im verdienten Urlaub. EIn Workaround ist auch bereits beschrieben: Zweite Web instanz anlegen und dort websockets nutzen und editor darüber und andere webinstanz für die app |
Super, danke! |
Klinke mich hier auch ein, jedoch ist es hier etwas kritischer da sämtliche ws-Optionen bei mir leider gar nicht funktionieren. Bin also auf die "Non-WS"-Variante angewiesen... |
@kopierschnitte Was meinst Du mit "gar nucht funktionieren? Wenn es bei den anderen usern funktioniert warum sollte das bei dir dann nicht tun? |
@Apollon77 Sorry, wollte damit sagen, dass bei mir die VIS bei Nutzung von WS nicht mehr startet (bleibt in der Zählschleife mit dem Kreis). Update: Nutze jetzt die latest-Versionen vom Web-, Socket- und WS-Adapter. Damit klappt das Editieren (und Anzeigen) im WS-Modus. |
Mit "reine Web-Sockets verwenden" ist zwar auch bei mir der Fehler "Verbindungsfehler" im Vis-Editor weg, jedoch funktioniert die Visualisierung auf dem Android-Gerät mit der ioBroker-App im heimischen Netzwerk nicht mehr. Im Browser wird die Visualisierung angezeigt, sowie auch in der ioBroker-App über die Cloud.
|
This is exactly the issue: vis app only works with an web instance where "pure websockets" is disabled. We will clean that up |
@Apollon77 Danke |
@ingo: Vorab übrigens ein schönes Weihnachtsfest und einen guten Rutsch! p.s.: Wie schon oft gesagt... für das bedienerlose oder mindestens personalarme Betreiben eines Atomkraftwerks würde man diese Plattform vielleicht nicht unbedingt nehmen - aber für GLT Gebäudeleittechnik und sophisticated Smart- oder Intelligent-Home-Anwendung: Es gibt nichts Besseres! |
Danke! |
@Apollon77 Folgendes ist mir noch aufgefallen: Vielleicht hilft dies bei der Fehlersuche. |
Describe the bug
My understanding is that editing in a browser's window is not written to the VIS in iOBroker.
To Reproduce
Steps to reproduce the behavior:
Simple: Just editing a basic number leading HTML text (eg: From "This" to "That") is shown in the edition window but obviously not updated to the VIS iOBroker base.
Opening this updated view in 8082/vis/index.html....... does not show the change, even after reloading this window, of course.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots & Logfiles
Updates in the VIS-edit should be written to the base and should be shown in clients.
Versions:
Additional context
Even tried different browsers (Firefox, Safari, Chrome) and the behavior is identical.
Even rebooted the Mac, of course.
Even restarted the iOBroker.
What might this be, where can I start changing something in the environment?
The text was updated successfully, but these errors were encountered: