Icons no longer updating in BasicUI


(Mike Dilger) #10

Ok, I updated to build #535 today and the problem seems to be when running the Basic UI under Firefox and Chrome (both latest versions) on WIN 7. It also does not work on Safari on the iPad. However it does work OK on IE v11 running on WIN 7 (not my favourite choice of browser).

I can confirm the following:

Firefox

  • Basic UI does not automatically refresh
  • HABpanel refreshes as expected
  • Classic UI refreshes as expected
  • HABmin refreshes as expected
  • Paper UI refreshes as expected

Chrome & Safari - as per Firefox

IE v11 - Basic UI refreshes as expected!

The items I am testing are quite simple. The definitions are as follows:

MQTT item - data is currently updated every 5 seconds

Number temp_return "Return Temperature [%.1f °C]" <temperature> (temperature , GF_Mancave) { mqtt =
"<[mqttService:myHouse/services/hvac/unit1/temp2:state:default]" }

Dimmer Item - each UI should reflect any change automatically

Dimmer Light_GF_mancave_Ceiling "LED Spot" (GF_Mancave , Lights)

Perhaps this is related to: https://github.com/eclipse/smarthome/issues/2295 but that does not explain the fact that it works on IE.

P.s. the above is true if I run Firefox on the both the server and my development PC.


(Jim) #11

build 536 is no better. Will open a ticket tomorrow.


(Stefan) #12

I can confirm that there are several issues with refresh. But I have also seen differences between icon updates, state updates and even valuecolor updates.

I have a Switch (based on presence detection), where I get icon updates and state updates (both on BasicUI and ClassicUI), but the defined valuecolor doesn’t change in BasicUI.

Then I have another Switch (door contact), where I do not get any updates. No icon, no state update. Both in ClassicUI and BasicUI. PaperUI and HABmin meanwhile do get updated. Of course, after a refresh the browser (Safari) also gets updated. So it’s definitly an UI issue. And at least the state update has worked with an older build. But I never got an icon update (AFAIK) for this Switch (that could be related to other issues though…).

I am using #536 and have tried this with Safari on OS X 10.12. A quick check with Chrome showed the same behavior.

So not exactly the same behavior as above, but also clearly a related issue.


(Ben Clark) #13

Strange, I updated again to 536 to see if I could replicate and am still getting instant updates with no problems with icons. Windows 10, Chrome.


(Stefan) #14

Do you use zwave devices? The switch item with problems is a zwave device and the switch item which is working isn’t (presence detection with exec binding). So maybe we can reduce this to zwave devices?

If you have zwave devices acting as a SWITCH item, which device is it (light, door sensor etc.)? I have used my door sensor in OH1 as CONTACT with working icon updates. In OH2 it isn’t a CONTACT any longer, but a SWITCH. So maybe that’s the problem as the according dynamic icon is an -open/-closed icon and no -on/off-icon. Which icon do you use? OH2 standard icons or individual?


(Ben Clark) #15

I tested this on another browser and got the same issue you’re having now. Even stranger I have gone back to chrome and now no icon or status updates are working! The Event items are coming up as failed after their first load.

This happens for all of my items, not just zwave.


(Vlad Ivanov) #16

IE does not support server-side events and therefore uses a fallback — longpolling request mode.


(Ben Clark) #17

After a while and without doing anything, my status updates and icons are working again. I am at a loss in understanding what’s going on here.

What network traffic looks like when events are working:


(Jim) #18

ticket opened: https://github.com/eclipse/smarthome/issues/2322


(Wouter Born) #19

A fix has been merged in ESH and should be part of openHAB within the coming days.

For people who can’t wait, there is also a bundle with the fix, see: https://github.com/eclipse/smarthome/issues/2322#issuecomment-254593811


(Matthew Clegg) #20

Did this get included into openhab 2.0 as i’m having the same problem with basicui on openhab 2.0


(Wouter Born) #21

Yes the fix is included in the final openHAB 2.0 release. It should also be included in development releases that were downloaded some days after the merge took place on October 18th, 2016.


(Matthew Clegg) #22

ok, so it looks like there are still issues with basicui updating in chrome, but not IE


(Matthew Clegg) #23

other way round Not updating in Chrome but updating in IE


(Wouter Born) #24

I haven’t seen this issue myself lately. Only when items are added added/removed from a sitemap updates break for me. Restarting openHAB resolves that for me.

Is this your issue?


(Matthew Clegg) #25

Pretty much, but i have just a manually operated switch and a dynamic icon. If i switch tin paper ui it doesn’t reflect status in Basic UI on chrome, but it does on IE.

Equally if i manually flip the switch on basic ui on chrome the icon doesn’t change, if i do the same on IE it does.


(Joe Palazzolo) #26

Wouter nailed it for me. I restarted my OpenHAB box and the lamp icons now change to reflect the state of the switch. I hadn’t had to restart since my initial config, so I had been refreshing my Chrome browser until now to see the icon change. Thanks Wouter!


Need help with ELK/NESS alarm status over serial
(Wouter Born) #27

Glad that it also solved your issue @OpenHABJoe! :slight_smile: The issue that Basic UI updates stop working after changing your configuration is reported in this issue:


Openhab2 classic and basic ui not working
(Bob Barbagallo) #28

Having the same problem here. Started last week. The problem is on Chome and Firefox with Basic UI. Edge and the iPhone app tracks fine. I don’t know if this is a coincidence, however, when I tried HABPanel for the first time (it tracks ok), Basic UI stopped tracking. I’ve tried Basic UI on a Mac and a PC under chrome and have the same issue. Seems to be browser based.

Hope this helps finding a solution.

Bob


(Mike Miller) #29

I know this thread is a bit old, but as I am just now migrating to OH2 (well, more like using the opportunity to completely rebuild) I am noticing this same exact thing. In fact, it is exactly still as @MikeD mentions above.

I have even confirmed something else as well - I am currently only using exec binding and everything is working well. I use 2 different scripts - a codesend script for GPIO activation for my 433’s and an ssh command sent to my rooted Gen 1 WinkHub that controls nothing but Zigbee devices.

Here is the weird thing and my addition to this thread - for the 433’s, the UI updates as expected. For the ssh script that operates the Zigbee bulbs, I see the behavior listed int the quote below. I have no idea what would possibly be different between the 2, but there clearly is.

I have not tested on Android app, but have on the iPhone app. If I invoke the commands from the app, the behavior listed in the quote applies; however, if I invoke from any browser on my PC, it DOES update all of them properly on the iPhone app.