search

eclipse-archived / smarthome

Eclipse SmartHome™ project
https://www.eclipse.org/smarthome/
Eclipse Public License 2.0
865 stars 782 forks source link

missing patterns / formatting causes values to be non persistent\ vanish on Basic UI #1166

Closed thesebastianf closed 7 years ago

thesebastianf commented 8 years ago

See here for details

https://community.openhab.org/t/values-door-motion-on-basic-ui-vanish-happens-on-multiple-zwave-devices/8424/9

kaikreuzer commented 8 years ago

Could you come up with an easy reproducible case, possibly based on the demo setup?

If I e.g.

  1. open http://localhost:8080/basicui/app?w=020102&sitemap=demo
  2. call smarthome:update Window_GF_Frontdoor CLOSED on the console
  3. refresh http://localhost:8080/basicui/app?w=020102&sitemap=demo I see "closed" as a label text and all is fine. So what is the difference to your use case?
thesebastianf commented 8 years ago

to make it better understandable I made a screencast --> https://youtu.be/661VUqKWsdk what you see.

  1. basic ui is already open --> DOOR SENSOR = blank
  2. I open / close the door sensor
  3. this is being updated on UI instantly
  4. I refresh webpage
  5. last state is not shown --> blank
  6. I show "items" on oh2 shell --> state of the item is CLOSED
  7. I would expect that CLOSED is shown on UI after refresh
kaikreuzer commented 8 years ago

Ok, but again my question: Can you come up with an easily reproducible description? What could be the difference to my setup from above?

tavalin commented 8 years ago

Sounds like it might be a javascript/rendering issue. I had a similar issue when I used the Squeeze Box binding. The track details would disappear from the UI even though the track playing time was increasing.

thesebastianf commented 8 years ago

Well difference.... Demo Setup is still in conf Folder? My stuff is in mapdb?

Only difference i could see. First I thought it might be zwave related. But another uses said same issue with knx.

yphyph01 commented 8 years ago

Hi, For my case: items file: Contact cAlarmTotal "Alarme Armement Total" <present> (grSecurity) {knx="8/0/5"} Contact cAlarmZone1 "Alarme Armement Partiel 1" <present> (grSecurity) {knx="8/0/6"} Contact cAlarmZone2 "Alarme armement Partiel 2" <present> (grSecurity) {knx="8/0/2"} Sitemap: Group item=grSecurity label="Sécurité"

@kaikreuzer : I don't know the difference with your case, but I confirm that your case is working, status are persistent on the screen on my browser but my case doens't work.

To update my cAlarmeIncendie tiem, I've called the command image and the "closed" status appears correctly on PaperUI screen, but after a refresh, it's disappered.

Same thing for other Contact Items Type binded to KNX.

thesebastianf commented 8 years ago

also happens for yahooweather binding added thing via paper ui manually. added to sitemap: Text item=yahooweather_weather_9c6ef2f2_temperature

"items" does always show the correct temp value UI only when update is coming in during page is already open

maybe easier to reproduce?

s-simma commented 8 years ago

I had exactly the same problem . Device state (in my case a dimmer) was updated correctly while i was on the actual page Reentering the page or refresh does not show the actual state.

reason: The update state from the binding was not accepted by ESH but the state was still forwarded to the Basic-UI (I used DECIMAL type instead of PERCENTAGE type to update the state). my sugestion: switch karaf to debug mode and check if there is a DEBUG message after you change the state of your device.

thesebastianf commented 8 years ago

That sounds good. Will check later today and update issue accordingly.

thesebastianf commented 8 years ago

@s-simma hi you mean start in the debug mode via start_debug.sh or log:set DEBUG ? << which component?

thesebastianf commented 8 years ago

@kaikreuzer I tested the mentioned reason from s-simma above. can fully confirm that basic ui expects a specific formatting. when I changed that it does work.

still I think this is not the it should be and therefore a bug?

s-simma commented 8 years ago

I think it is the other way round. The core does not accept the wrong type but still creates an event for the Basic-UI. And the Basic-UI can obiously accept it.

maggu2810 commented 8 years ago

Have you the autoupdate mechanism enabled or disabled (see org.eclipse.smarthome.core.autoupdate)

thesebastianf commented 8 years ago

how would I check that?

maggu2810 commented 8 years ago

Depends on your runtime environment. Eclipse IDE, Karaf, ...

You have to look for the bundle "org.eclipse.smarthome.core.autoupdate".

Start the same test without that bundle running and look if the problem still exists.

thesebastianf commented 8 years ago

bundle:list START LEVEL 100 , List Threshold: 50

ID | State | Lvl | Version | Name

11 | Active | 80 | 2.22.1 | jersey-min 12 | Active | 80 | 2.3.0.201506221200 | JAX-RS Gson Provider 13 | Active | 80 | 5.3.0.201512270850 | OSGi JAX-RS Connector 14 | Active | 80 | 2.3.1 | Gson 15 | Active | 80 | 10.0.1.v201203051515 | Guava: Google Core Libraries for Java 1.5 16 | Active | 80 | 3.0.0.v201312141243 | Google Guice (No AOP) 22 | Active | 80 | 3.2.0.v201101311130 | ANTLR Runtime 23 | Active | 80 | 1.6.0 | Commons Codec 24 | Active | 80 | 3.2.1 | Commons Collections 25 | Active | 80 | 1.1 | Commons Exec 26 | Active | 80 | 2.2.0 | Commons IO 27 | Active | 80 | 2.6 | Commons Lang 28 | Active | 80 | 3.2.0 | Commons Net 49 | Active | 80 | 4.0.3 | Apache Karaf :: Shell :: Core 52 | Active | 80 | 4.0.3 | Apache Karaf :: Wrapper :: Core 53 | Active | 80 | 3.1.0.7 | Apache ServiceMix :: Bundles :: commons-httpclient 55 | Active | 80 | 2.10.1.v20150123-0348 | EMF Common 56 | Active | 80 | 2.10.2.v20150123-0348 | EMF Ecore 57 | Active | 80 | 2.10.2.v20150123-0348 | EMF XML/XMI Persistence 58 | Active | 80 | 3.7.0.v20150402-1709 | Common Eclipse Runtime 59 | Active | 80 | 3.6.0.v20150318-1503 | Extension Registry Support 85 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Config Core 86 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Configuration Discovery 87 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Config Dispatcher 88 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Config XML 89 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Core 90 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome AutoUpdate Binding 91 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Core Binding XML 92 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Core ID 93 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Core Persistence 94 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Scheduler Service 95 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Core Thing 96 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Core Thing XML 97 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Transformation Service 98 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Console 99 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Console for OSGi runtime Karaf 100 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Monitor 101 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Net I/O Bundle 102 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome REST Interface Bundle 103 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Core REST API 104 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Sitemap REST API 105 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome SSE REST API 106 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Voice I/O Bundle 107 | Active | 85 | 0.8.0.201603141848 | Eclipse SmartHome Model Core 108 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Item Model 109 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Item Model Runtime 110 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Persistence Model 111 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Persistence Runtime 112 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Rule Model 113 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Rule Runtime 114 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Script 115 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Script Runtime 116 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Sitemap Model 117 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Sitemap Runtime 118 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Thing Model 119 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Thing Model Runtime 120 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome MapDB Storage Service 121 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome UI 122 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome UI Icons 123 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Classic IconSet 124 | Active | 80 | 2.6.2.v201407030533 | Xtend Runtime Library 125 | Active | 80 | 2.6.2.v201407030533 | Xtext 126 | Active | 80 | 2.6.2.v201407030533 | Xtext Common Types 127 | Active | 80 | 2.6.2.v201407030533 | Xtext Utility 128 | Active | 80 | 2.6.2.v201407030533 | Xbase Model 129 | Active | 80 | 2.6.2.v201407030533 | Xbase Runtime Library 131 | Active | 80 | 5.0.1.v201404251740 | ASM 132 | Active | 90 | 2.0.0.201603142138 | openHAB Core 133 | Active | 80 | 2.0.0.201603142138 | openHAB Karaf Integration 139 | Active | 80 | 1.1.0.201512270850 | Swagger Provider 140 | Active | 80 | 1.5.5.sp1 | swagger-all 141 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Basic UI, Fragments: 145 142 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome WebApp UI 143 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Paper UI, Fragments: 149 144 | Active | 80 | 2.0.0.201603142138 | openHAB REST Documentation 145 | Resolved | 80 | 2.0.0.201603142138 | openHAB Basic UI Fragment, Hosts: 141 146 | Active | 80 | 2.0.0.201603142138 | openHAB Classic UI Fragment 147 | Active | 80 | 2.0.0.201603142138 | openHAB Dashboard UI 148 | Active | 80 | 2.0.0.201603142138 | openHAB Classic Iconset 149 | Resolved | 80 | 2.0.0.201603142138 | openHAB Paper UI Theme Fragment, Hosts: 143 150 | Active | 80 | 4.2.3 | Apache HttpClient OSGi bundle 151 | Active | 80 | 4.2.3 | Apache HttpCore OSGi bundle 152 | Active | 80 | 0.8.0.201603141848 | Sonos Binding 153 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome UPnP Transport Bundle 154 | Active | 80 | 2.1.0 | JUPnP Library 155 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Wemo Binding 158 | Active | 80 | 2.0.0.201603170203 | avmFritz Binding 159 | Active | 80 | 2.0.0.201603170203 | Samsung Tv Binding 160 | Active | 80 | 1.9.0.201603160216 | openHAB Exec Binding 161 | Active | 80 | 2.0.0.201603142138 | openHAB 1.x Compatibility Layer 162 | Active | 80 | 1.9.0.201603160216 | openHAB RRD4j Persistence Bundle 163 | Active | 80 | 1.9.0.201603160216 | openHAB Mail Action 164 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome RegEx Transformation Service 165 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Exec Transformation Service 166 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome Map Transformation Service 167 | Active | 80 | 2.0.0.201603170203 | my.openHAB Service Bundle 168 | Active | 80 | 0.8.0.201603141848 | YahooWeather Binding 172 | Active | 80 | 2.0.0.201603151333 | HABmin User Interface 179 | Active | 80 | 2.0.0.201603170203 | ZWave Binding 180 | Active | 80 | 2.0.0.201603142138 | openHAB Serial Transport Bundle openhab>

maggu2810 commented 8 years ago

What do you want to show me?

This one?

90 | Active | 80 | 0.8.0.201603141848 | Eclipse SmartHome AutoUpdate Binding
thesebastianf commented 8 years ago

Sorry. Forgot to comment. Yes - that one. Just to be sure if that's the Autoupdate to deactivate. Since it says something about binding.? Wasn't sure.

Btw Using my.openhab and starting basic UI through my.openhab....the values are shown. However I assume that Service uses values synched with it and is therefore totally different.

maggu2810 commented 8 years ago

openHAB is using Karaf, so to administrate your openHAB system, we need to read that documentation a little bit. That is not Eclipse SmartHome specific.

https://karaf.apache.org/manual/latest/commands/bundle-list.html

If you use bundle:list without e.g. "-s" you do not see the Bundle Symbolic Name but the Bundle Name. You could e.g. try bundle:list 90 and bundle:list -s 90 to see the difference. You could also try e.g. bundle:list org.eclipse.smarthome.core.autoupdate

If you want to stop a bundle you could use https://karaf.apache.org/manual/latest/commands/bundle-stop.html

thesebastianf commented 8 years ago

I appreciate that you take the time to explain a little :)

unfortunately stopping the bundle did not solve the issue

maggu2810 commented 8 years ago

@shorty707 I am a little confused about the autoupdate mechanism at all and started a forum thread some time ago (but need some anwers myself). If the autoupdate is the root case of your problem has been just a idea. I have not had a deeper look into it at all.

thesebastianf commented 8 years ago

I think its all related to patterns / formatting

when I look in REST some items have a pattern tag for formatting while others do not. since I did not manually format these.... e.g. see screenshot below temp vs battery where is that formatting coming from? and how can all of them have a pattern?

items with a valid patterns do show properly on ui item without not...

I thought this is something from the binding but chris says:

Chris Jackson: "State descriptions are defined in the channel definition. I defined some like you see, but the battery is a system channel so can't be changed in the zwave binding. I though that state descriptions were also updated by the item definition, but I'm not sure about that."

image

cdjackson commented 8 years ago

You already asked this exact question here (https://community.openhab.org/t/testing-z-wave-binding-on-openhab-2/7522/1079 https://community.openhab.org/t/testing-z-wave-binding-on-openhab-2/7522/1079) complete with the same image. As I said earlier, the state descriptions are provided in the XML files. For temperature, I update this as it’s a Z-Wave channel. For the battery, this is a system channel so it’s defined in the system and not in the Z-Wave binding.

thesebastianf commented 8 years ago

I know therefore I updated this issue with the information i learned from you and quoted you 👍 By how I interpreted what you wrote i thought its not an zwave issue but esh or basic ui.

Basic Ui: I think even without formatting the values should not vanish from the ui. ESH: System channels should have a formatting \ pattern Zwave: no issue here :-)

triller-telekom commented 7 years ago

Recently there have been a lot of changes/fixes to the basic UI regarding refresh/status update with formatting etc.

@shorty707: Could you please try your scenario again with the latest openHAB openhab-2.1.0-SNAPSHOT.tar.gz ? You can download it from here: https://openhab.ci.cloudbees.com/job/openHAB-Distribution/

Please report if the issue still exists.

kaikreuzer commented 7 years ago

As this is indeed pretty old, I would also hope that it is fixed meanwhile through the many changes that have been done. If this is not the case, please feel free to re-open the issue.