Setpoints and Drayton binding in 3.4

Setpoint items seem to not work in web browsers on BASIC UI, but are fine on the Android APP.

image

I have tried both Edge browser and Brave (Chrome) browser. Nothing happens if you click on either button (even if you refresh the page). I have tried fully wiping the browser history+cache etc.

Was it working differently in previous OH3.x versions ? I have no memory of any change in that part in OH 3.4.
And no memory of Git issue.

Edit : I found that fix merged in January 2021, almost 2 years ago:

Just FYI. Using Safari or Chrome the BasicUI Setpoint seem to work fine on my setup, so I don’t think this issue is broad scope for OH3.4

So this would be a specific browser issue using Edge or Brave?
In that case a Git issue must be open.

I only as recent as 30 days ago upgraded to OH3.3, so I cant say for certain, however, I did re-write the entire configuration at this time, to move over from 2.5. I am using Items files for my sitemap. I mostly use my mobile phone for interacting, so not sure if this was or wasnt an issue before on OH 3.3 as I may not have tested it.

I have found one strange thing. If I open the sitemap/BasicUI and go to my setpoint item, I cannot change it (as described), but if I then leave that page open on my web browser, open the sitemap on my phone, change the setpoint item, this is then reflected in the web browser AND THEN I can also change it in the web browser. I’ve tried this twice, with the same result. Process as follows:

  • Open MS Edge or Brave.
  • Wipe history + cookies + cache
  • Go to http://openhab:8080/basicui/app?w=0400&sitemap=SITEMAPNAME in Edge/Brave
  • Try to change the setpoint item (THIS DOES NOT WORK)
  • Open the Openhab App on my phone and go to change the setpoint Item (This works and is shown on the Edge/Brave web page).
  • I can now change the setting on the Edge/Brave web browser page, until I next close the page and re-open it.

I have also tried Chrome and Firefox, with the same result. I am on a Windows 10 machine, just the standard MS Antivirus.

I have also tested on a Ubuntu 22.04 with Firefox and the same result.

Nothing is in my Openhab.log file that I can see.

So not sure if this is an OH 3.x issue or 3.4 issue.

Thanks

@ewrw : please show your item definition and how is defined your sitemap. What binding)channel this item is linked to?

I need to make a correction to what I said… Im not using an Items file, only a Sitemap file. All Items are imported/created in the OH3 web interface. (sorry for the confusion there).

The actual setpoint item is linked to the Drayton Wiser binding/channel for setting the temperature.

The items, other than renaming them, are a copy/paste of the example shown in the example of the binding. They are the Setpoint Temperatures shown in the example Items and Sitemap file respectively.

So my Sitemap file looks like:

And the Item (generated/imported in the web interface)


I can also confirm that I have some other setpoints in my sitemap, that are purely to do with expire timers on automated lights (set the time duration from a motion trigger to the light switching off). These DO work absolutely fine and I can change the setpoint item within the web interface. These automated light setpoints run DSL code to update the metadata expire timer on a couple of Items and so dont interact with any binding.

So my conclusion is my issue is somehow linked purely to the Drayton Wiser binding and/or something generally to do with bindings that isn’t part of the internals/core of Openhab.

Thanks

The Drayton Wiser binding only accepts a QuantityType for this channel.

Pkease check in events.log what command is aent when you use the UI and nothing happens.
IMHO, the binding should have handled at least also DecimalType. But I am not sure what commands are produced by BasicUI for the setpoint widget, that is the reason why I ask you to check the logs.

Hiya!

I couldn’t see anything in my logs relating to “Drayton…” (the Item/Setpoint) when I clicked on anything in the interface, while the log was set at DEBUG (log:set DEBUG openhab.event)

So I upped the log level to TRACE (log:set TRACE openhab.event) hoping that may yield different results… but nothing

I tried to click the up/down about 20x, then I hunted the log for:

openhab.event
drayton
setpoint

There was nothing in the logs that seemed to reference I had clicked on anything within the web interface. I repeated the whole process again, just to confirm the result.

Obviously other things, relating to other items were logged (none of them relevant to the interface or anything with the Drayton binding/items)

I did also after this test, go to the Android app for BasicUI and change it there. The following was logged:

2022-12-23 10:45:17.564 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Draytontoproom_setpoint' received command 23 °C
2022-12-23 10:45:17.565 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Draytontoproom_setpoint' predicted to become 23 °C
2022-12-23 10:45:17.587 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Draytontoproom_setpoint' changed from 22.5 °C to 23 °C

So I think Im logging with the correct settings, but let me know if not?

Also… yes it does log as “penhab.event.ItemStatePredictedEvent” (the middle event)

Thanks

@ewrw : please open a separate topic for your issue with BasicUI and the Drayton binding.

When I asked to check the logs, I was thinking about events.log.

My idea was the the initial value was without unit, for example 22. BasicUI would then send 22.5 when you click the up button. This command would then be ignored by the binding because the binding unfortunately only expects a value with a unit.
Using the Android app, the value ia then set to 22.5 °C. At this step, BasicUI has knowledge of the unit and will then send 23 °C when you click on the up button (a command accepted by the binding).

All this makes fully sense if you can find the initial 22.5 command in events.log.

While the value has a init, is it working in BasicUI when you open the page and click the up button?

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.