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
-
Release pimatic-raspbee@0.1.6
-
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.
-
You seems beeing right. The open/close values are exactly the other way round:
open: lift: 100
stop: lift: 50
close: lift: 0But looking again at it, I’m wondering, that the status of “open” is exactly the other way round I would have awaited.
open: “open”: false
close: “open”: true
That device really seems a bit ‘special’ …
… or something went wrong in the deconz implementation …? But switching the buttons in the deconz-gui, trigger the device button correctly. The other way round, triggering by the device’s buttons, I do not know.open sends:
20:44:41.520 [pimatic-raspbee] debug: Received values: { 20:44:41.520 [pimatic-raspbee] debug:> "id": 2, 20:44:41.520 [pimatic-raspbee] debug:> "type": "event", 20:44:41.520 [pimatic-raspbee] debug:> "event": "changed", 20:44:41.520 [pimatic-raspbee] debug:> "resource": "lights", 20:44:41.520 [pimatic-raspbee] debug:> "state": { 20:44:41.520 [pimatic-raspbee] debug:> "bri": 254, 20:44:41.520 [pimatic-raspbee] debug:> "lift": 100, 20:44:41.520 [pimatic-raspbee] debug:> "on": true, 20:44:41.520 [pimatic-raspbee] debug:> "open": false, 20:44:41.520 [pimatic-raspbee] debug:> "reachable": true 20:44:41.520 [pimatic-raspbee] debug:> },
stop send:
20:44:45.327 [pimatic-raspbee] debug: Received values: { 20:44:45.327 [pimatic-raspbee] debug:> "id": 2, 20:44:45.327 [pimatic-raspbee] debug:> "type": "event", 20:44:45.327 [pimatic-raspbee] debug:> "event": "changed", 20:44:45.327 [pimatic-raspbee] debug:> "resource": "lights", 20:44:45.327 [pimatic-raspbee] debug:> "state": { 20:44:45.327 [pimatic-raspbee] debug:> "bri": 127, 20:44:45.327 [pimatic-raspbee] debug:> "lift": 50, 20:44:45.327 [pimatic-raspbee] debug:> "on": true, 20:44:45.327 [pimatic-raspbee] debug:> "open": true, 20:44:45.327 [pimatic-raspbee] debug:> "reachable": true 20:44:45.327 [pimatic-raspbee] debug:> },
close sends:
20:44:48.319 [pimatic-raspbee] debug: Received values: { 20:44:48.319 [pimatic-raspbee] debug:> "id": 2, 20:44:48.319 [pimatic-raspbee] debug:> "type": "event", 20:44:48.319 [pimatic-raspbee] debug:> "event": "changed", 20:44:48.319 [pimatic-raspbee] debug:> "resource": "lights", 20:44:48.319 [pimatic-raspbee] debug:> "state": { 20:44:48.319 [pimatic-raspbee] debug:> "bri": 0, 20:44:48.319 [pimatic-raspbee] debug:> "lift": 0, 20:44:48.319 [pimatic-raspbee] debug:> "on": false, 20:44:48.319 [pimatic-raspbee] debug:> "open": true, 20:44:48.319 [pimatic-raspbee] debug:> "reachable": true 20:44:48.319 [pimatic-raspbee] debug:> },
-
endurance? - will I have to click 200-times? …
Btw.: Today the in-wall mounted shutter device arrived.
It is this one, also already implemented in deconz:
I directly learned it via Phoscon and joint it to Pimatic. Here also your raspbee cover device works! Thus two devices implemented at once
But what I recognized, having it really correctly connected with N (neutral) and L (phase) to ~230V the circuit points are working the other way round.
Means after really double-checking:
Pressing ‘open’ in the raspbee gui gives ~230V to 'arrow down’
Pressing ‘down’ in the raspbee gui gives ~230V to 'arrow up’
Everything else exactly works like as with the other shutter.
But as this device anyhow doesn’t have own buttons and no lights, it doesn’t matter. One can simply connect it the other way round -
@bertreb said in Release pimatic-raspbee@0.1.6:
inverted option
that now really sound like luxury but super idea!
Thinking about next steps, as I remember, that in the beginning I had to exchange 6 files in total and I did all this things for sure currently on my Dev/Test system.
Are you going to plan these implementations to go to an official Raspbee update?