You only updated raspbee.coffee?
-
yes only …
-
no, didn’t work, allthough I additionally deleted the device from Pimatic and then got it newly in
The slider, the percentages and the status now are working perfectly - incl. steering the device.
And also when moving the slider, the ‘open/close’ buttons of the raspbee device are managed propperly. -
sorry no, all works, except the usage of the ‘open/close’ buttons
they cause an error ‘bad request’, which is wondering, as they worked propperly before -
ok, last test for today
-
@bertreb YOU MADE IT
Working perfectly now - without the error messages. The ‘tilt’ parameters were the issue!
Only as a thought and really not to drive you crazy with that thing
As now - surely as agreed - no parameter (percentage open or tilt) is coming back from the device, surely if someone moves it manually, the gui doesn’t represent the correct status.
Maybe this can be read after moving has stopped and then put to the slider and the percentages …
Definetly luxus but then it would be perfectBut not today, have a good night now.
And great thanks -
Hi again, did a short test during my lunch time
What I see, is that we have the similiar behaviour as at one point of time before, that what is received from the shutter device, is shown in the raspbee gui exactly the other way around.
Means: From the raspbee gui, the complete steering works 100% perfect, but what come from the shutter device, is reflected in an reversed manner in the gui.
As example how the behaviour currently is when using the shutter device buttons:
- Having the shutter in the raspbee gui on e. g. 50%.
- Pressing then ‘close’ on the shutter device button and 2 sec after directly pressing ‘stop’ there
- makes the raspbee gui move to ‘60% open’ (slider+percentages).
Thus maybe what comes in here, might have to be negotiated in the same range in the other direction (calculating 40% out of the sent 60%) or maybe instead of a calculation, directly capturing the received ‘close’ and making an ‘open’ out of it in raspbee, to move slider and percentages in the right direction.
… that was why I below already phrased ’ …’ not to drive you crazy’
An additional point:
I was now already looking myself into the raspbee.coffee and searching for the maybe right parameters as I already formerly have been able to identify the ‘tilt’ values, which you then corrected.
What editor do you use to maintain the files? - with a normal ‘notepad’ that will not work … -
I’m using sublime3 with betterCoffee plugin.
The change i made in the last version was handling the open / close buttons on the shutter (only if not already an action was running from the gui).
What needs to be tested if open and close aren’t reversed? -
You mean what else beyond the reverse behaviour?
I currently see nothing more.Ouo: Have to run , will be back in the evening …
-
What i mean with reverse(inverted) is the following.
When you push open on the shutter, the plugin moves to close. And when you push close the plugin moves to open.
Because what you describe looks like the open and close are inverted (in my plugin) -
Exactly as you described. But it is only inverted, when pushing from the shutter device.
When pushing from the plugin, the device is pushed correctly. -
Ok, I will test then in the evening
-
A check on the buttons on the shutter.
The button symbols are:
upper: “< >” is open
middle “||” is stop
lower: “> <” is close
Is this correct?Can you post again the ‘new message received’ values when pushing the upper button (open) and pushing the lower button (close)?
I ask this because the shutter device should send, when pushing a button on the shutter:
button open-> lift: 0
button close-> lift: 100
button stop-> lift: 50
These open and close values are in accordance with the posts on the Deconz forum and the Deconz api description.But it seems that open and close are switched, so please check that.
-
Hi @bertreb, it works like a charm
All buttons (device/gui) do trigger each other in a perfect way.
The shutter looks like:
And thus you are correct.I will check the lift values now.