I updated the raspbee.coffee with the open/close from the shutter inverted.
-
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?
-
I made already a pull-request for an earlier version, but that’s not being pick up.
So lets wait a bit.And is the lift when you push open 100 and when push down 0 ?
Looks that these value are inverted also. That means an inverted option for sending and an inverted option for receiving.
-
I simulated now, that the in-wall device is switched via it’s local switch circuit connectors - simply bridging the conact by a cable. First it doesn’t look that it sends something back to Raspbee, but I checked the log and there has been something received. And there is always an error message regarding ‘lift’ in the end, which hasn’t been there with the other device.
Switch contact 1 gives back:
22:22:45.429 [pimatic-raspbee] debug: new message received 22:22:45.431 [pimatic-raspbee] debug: { e: 'changed', 22:22:45.431 [pimatic-raspbee] debug:> id: '3', 22:22:45.431 [pimatic-raspbee] debug:> r: 'lights', 22:22:45.431 [pimatic-raspbee] debug:> state: { bri: 63, lift: 25, on: true, open: true, reachable: true }, 22:22:45.431 [pimatic-raspbee] debug:> t: 'event', 22:22:45.431 [pimatic-raspbee] debug:> uniqueid: '84:71:27:ff:fe:c4:3c:5d-01' } 22:22:45.432 [pimatic-raspbee] debug: Received values: { 22:22:45.432 [pimatic-raspbee] debug:> "id": 3, 22:22:45.432 [pimatic-raspbee] debug:> "type": "event", 22:22:45.432 [pimatic-raspbee] debug:> "event": "changed", 22:22:45.432 [pimatic-raspbee] debug:> "resource": "lights", 22:22:45.432 [pimatic-raspbee] debug:> "state": { 22:22:45.432 [pimatic-raspbee] debug:> "bri": 63, 22:22:45.432 [pimatic-raspbee] debug:> "lift": 25, 22:22:45.432 [pimatic-raspbee] debug:> "on": true, 22:22:45.432 [pimatic-raspbee] debug:> "open": true, 22:22:45.432 [pimatic-raspbee] debug:> "reachable": true 22:22:45.432 [pimatic-raspbee] debug:> }, 22:22:45.432 [pimatic-raspbee] debug:> "uniqueid": "84:71:27:ff:fe:c4:3c:5d-01" 22:22:45.432 [pimatic-raspbee] debug:>} 22:22:45.434 [pimatic-raspbee] debug: Lift action '25' not supported
switch contact 2 sent back:
22:22:39.813 [pimatic-raspbee] debug: new message received 22:22:39.815 [pimatic-raspbee] debug: { e: 'changed', 22:22:39.815 [pimatic-raspbee] debug:> id: '3', 22:22:39.815 [pimatic-raspbee] debug:> r: 'lights', 22:22:39.815 [pimatic-raspbee] debug:> state: { bri: 2, lift: 1, on: true, open: true, reachable: true }, 22:22:39.815 [pimatic-raspbee] debug:> t: 'event', 22:22:39.815 [pimatic-raspbee] debug:> uniqueid: '84:71:27:ff:fe:c4:3c:5d-01' } 22:22:39.817 [pimatic-raspbee] debug: Received values: { 22:22:39.817 [pimatic-raspbee] debug:> "id": 3, 22:22:39.817 [pimatic-raspbee] debug:> "type": "event", 22:22:39.817 [pimatic-raspbee] debug:> "event": "changed", 22:22:39.817 [pimatic-raspbee] debug:> "resource": "lights", 22:22:39.817 [pimatic-raspbee] debug:> "state": { 22:22:39.817 [pimatic-raspbee] debug:> "bri": 2, 22:22:39.817 [pimatic-raspbee] debug:> "lift": 1, 22:22:39.817 [pimatic-raspbee] debug:> "on": true, 22:22:39.817 [pimatic-raspbee] debug:> "open": true, 22:22:39.817 [pimatic-raspbee] debug:> "reachable": true 22:22:39.817 [pimatic-raspbee] debug:> }, 22:22:39.817 [pimatic-raspbee] debug:> "uniqueid": "84:71:27:ff:fe:c4:3c:5d-01" 22:22:39.817 [pimatic-raspbee] debug:>} 22:22:39.819 [pimatic-raspbee] debug: Lift action '1' not supported
-
Yes, i saw the diagram for this device. These are for local switches for up (switch right) and down (left).
The position is still calculated (timed) because i don’t see a sensor for that. -
@bertreb said in Release pimatic-raspbee@0.1.6:
And is the lift when you push open 100 and when push down 0 ?
let me check, have to re-connect the other device as I currently have only one test-cable on hand …
-
yes you’re right
open: lift -> 100
close: lift -> 0Ok lets continue then tomorrow.
-
@bertreb said in Release pimatic-raspbee@0.1.6:
I made already a pull-request for an earlier version, but that’s not being pick up.
So lets wait a bit.Ah yes, I found it now.
As I do have also already the siren on hand here, wouldn’t it make sense to do the implementation jointly with the shutter?
Sure I could steer it via the curl commands, but then e. g. I would not see if it is not online. -
I added the inverted option for out (to the shutter) and in (from the shutter)
Also i added a first draft of the RaspBeeWarning device, which can be used for the siren.
You need to update the files: action.coffee, device-config-schema.coffee, raspbee.coffee, /app/raspbee-template.coffee and /app/raspbee-template.jade -
Hi again, shutter inverting works super! - both directions
Siren also works in general.
What is wondering, is that the tampered status is false, regardless I press the respective contact or not.
I would also spend an option for that, as I fear this contact will not work propperly in each plug socket.You implemented two button for the alarm: ‘sound’ and 'long’
I guess that one is the really long alarm (length only to configure in the deconz-gui?) and the other one might be the 1sec test tone.
Currently both buttons seems working the same. Long alarm, unless I press 'off’
For the 1 sec. function I used this command:
curl -X PUT http://127.0.0.1:8080/api/A00915C575/lights/5/state -d ‘{“alert”:“select”}’ -s -
Nice that the covers update works.
For the sirens commands i used the deconz api:
off-> alert:none
silent-> alert: blink
sound-> alert:select
long-> alert:lselectYou can test it via the curl command and you can see what’s being sent in the debug log.
-
OK, that are exactly the parameters I also sent by the curl commands.
But I remember, that then also firstly the 1sec ‘select’ thing didn’t work propperly and then suddenly it worked.
I had no clue why …Another aspect I just checked, only not to forget about: It seems that the shutter is still not to steer by rule.