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.

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 …

I will make the send and received inverted config options tomorrow.
That will make it easier to tune a device to the shutter.

yes you’re right
open: lift -> 100
close: lift -> 0

Ok 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:lselect

You 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.

And can you check whats json is received when you tamper with the siren?

I switched the contact now several times, but there only something comes in when ‘opening’ the contact, resp. when I let the contact go (I believe) to it’s alarm position (pin looks out of the case)
It looks like this:

21:32:45.339 [pimatic-raspbee] debug: new message received
21:32:45.342 [pimatic-raspbee] debug: { attr:
21:32:45.342 [pimatic-raspbee] debug:>   { id: '4',
21:32:45.342 [pimatic-raspbee] debug:>     lastseen: '2021-02-25T20:32Z',
21:32:45.342 [pimatic-raspbee] debug:>     manufacturername: 'Heiman',
21:32:45.342 [pimatic-raspbee] debug:>     modelid: 'WarningDevice-EF-3.0',
21:32:45.342 [pimatic-raspbee] debug:>     name: 'WarnDev01',
21:32:45.342 [pimatic-raspbee] debug:>     swversion: '2020.8.20',
21:32:45.342 [pimatic-raspbee] debug:>     type: 'Warning device',
21:32:45.342 [pimatic-raspbee] debug:>     uniqueid: '84:2e:14:ff:fe:f5:21:79-01' },
21:32:45.342 [pimatic-raspbee] debug:>  e: 'changed',
21:32:45.342 [pimatic-raspbee] debug:>  id: '4',
21:32:45.342 [pimatic-raspbee] debug:>  r: 'lights',
21:32:45.342 [pimatic-raspbee] debug:>  t: 'event',
21:32:45.342 [pimatic-raspbee] debug:>  uniqueid: '84:2e:14:ff:fe:f5:21:79-01' }

In addition to smile: As from ‘ghost-hands’ suddenly the 1sec alarm works with the siren
Exactly as last time …

Seems there no tamper info coming from the siren.

I updated the action.coffee file. The cover rules should work now.
For now only stop, open and close are supported.

is there a special syntax to use?

The rule editor doesn’t offer the device by itself.
Here the offering of further commands/devices stops:

Also open or move seems not working …

PS.
This siren is a hell-machine. It starts howling also when it is plugged off from the power supply and then pressing the buttons in the gui … … thus normaly I would guess that this would be meaningful for the tamper functionality, however …

set raspbee …

ahhh! that now also works!

I think having ‘only’ these three options is, in context of a rule, sufficient enough, as then for sure by rule one can steer the seconds to move and then to stop…

well what to say - great work you did here the last evenings!
That was really impressing

Now it would be really cool, if @kosta (?) would find the time to migrate all the new features into a new raspbee version.

Will you try to request that again?

And the result is good.

It’s better to use the same logic to set the cover to a position.
So i added for the rule 'set raspbee <cover device id> to <0-100>'
Update the file action.coffee

And on updating pimatic-raspbee.
If @kosta is unavailable to update pimatic-raspbee. The alternative is to create an extended version called pimatic-raspbee-plus.
And like the cover and the siren more zigbee devices will popup and can be added to pimatic-raspbee-plus.