You could ignore it, but then you don’t need to use the buttons on the shutter and just see it as a Zigbee receiver.
Is still tilt:50% coming back as stop command?
-
Release pimatic-raspbee@0.1.6
-
As send in the logfile below, I guess that this is, what is send back:
(I explicitely waited in that round for the device flipping back to ‘stop’)21:33:11.888 [pimatic-raspbee] debug: new message received 21:33:11.893 [pimatic-raspbee] debug: { e: 'changed', 21:33:11.893 [pimatic-raspbee] debug:> id: '2', 21:33:11.893 [pimatic-raspbee] debug:> r: 'lights', 21:33:11.893 [pimatic-raspbee] debug:> state: 21:33:11.893 [pimatic-raspbee] debug:> { bri: 127, lift: 50, on: true, open: true, reachable: true }, 21:33:11.893 [pimatic-raspbee] debug:> t: 'event', 21:33:11.893 [pimatic-raspbee] debug:> uniqueid: 'ec:1b:bd:ff:fe:8f:10:92-01' } 21:33:11.894 [pimatic-raspbee] debug: Received values: { 21:33:11.894 [pimatic-raspbee] debug:> "id": 2, 21:33:11.894 [pimatic-raspbee] debug:> "type": "event", 21:33:11.894 [pimatic-raspbee] debug:> "event": "changed", 21:33:11.894 [pimatic-raspbee] debug:> "resource": "lights", 21:33:11.894 [pimatic-raspbee] debug:> "state": { 21:33:11.894 [pimatic-raspbee] debug:> "bri": 127, 21:33:11.894 [pimatic-raspbee] debug:> "lift": 50, 21:33:11.894 [pimatic-raspbee] debug:> "on": true, 21:33:11.894 [pimatic-raspbee] debug:> "open": true, 21:33:11.894 [pimatic-raspbee] debug:> "reachable": true 21:33:11.894 [pimatic-raspbee] debug:> }, 21:33:11.894 [pimatic-raspbee] debug:> "uniqueid": "ec:1b:bd:ff:fe:8f:10:92-01" 21:33:11.894 [pimatic-raspbee] debug:>}
-
nearly perfect
do I have to erase again ‘,js’?
Because I didn’t and now the close and the open buttons causes ‘bad request’ errors
-
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.