Release pimatic-raspbee@0.1.6
sounds good 
I meanwhile also found it again in the git deconz-rest-plugin docu.
There it seems to be the Tuya TS130F, as which it is also discovered by Phoscon.
Question: If your are going to change, the former device will also continue working, right?
Great!
Then enjoy your evening, but I will be able to come back Sunday evening earliest.
Buy for now 
an additional thougth:
I was just again in the deconz gui to verify my yesterdays experiences how to calibrate the moving time, means the time from pressing e. g. ‘open’ (from closed position), until the switch toggels back himself to ‘stop’
This adjustment can be done also via the deconz gui:
Amongst the attributes in the ‘Window Covering’/‘Cluster Info’, there is one called ‘Calibration’ (0xF001), which can be set to ‘End’ and ‘Start’.
As I see the challenge to fetch the respective commands from deconz (as if deconz gui is running, we are not able to find anything in the Pimatic Log), I spent some research on github and at least found this:
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/general.xml#L1608
<attribute-set id="0xf001" description="Tuya Window Covering Setting">
<attribute id="0xf001" name="Calibration" type="enum8" default="0" required="m" access="rw">
<value name="Start" value="0"></value>
<value name="End" value="1"></value>
</attribute>
What do you think? Might it become possible to implement the Calibration function into the respective Raspbee-Device?
I made an update for the cover device.
The option ‘simulate’ is added and you should use it for your cover device.
Simulation is done by the plugin. It needs to be aligned with the shutter via the rollingTime
Please update raspbee.coffee and device-config-schema.coffee
Hi, that is a good idea, as that brings the flexibility in using the different devices.
Sure, exact synchronizing has to be done then with the real shutter moving time.
But currently is has one side effect.
You remember that behavior of the first type (TS0302), that he always jumps, when ‘stop’ is pressed or he toggles himself back to ‘stop’ after a while, and sets the lift value to 50%, which then is not the truth, as he is elseware.
That now happens again, e. g.:
Start position ‘closed’, then pressing ‘open’ and let him go.
When pressing ‘stop’ somewhere, he lets the gui jump to 50% and the same happens when letting him rum until 100%, as he then also let the gui show 50%. This is regardless ‘simulation’ is on or off.
Also when steering him by the gui, when stopping, in end position or somewhere else, the gui position is always pushed to 50%.
The behavior of the new shutter switch (TS130F) is correct.
Additional difference:
TS0302 shows continuous changing in the gui (10-20-30- …), but then jumps back to 50%, as explainded above.
TS130F does not show continuous changing in the gui, but when stopping, jumps to the correct number
The 2 devices are different and Deconz is not normalising them to the same behaviour.
I removed the 50% = stop, but for testing i got it back. Update raspbee.coffee.
Please test a bit with ‘simulate’ on and off
TS0302 continuous working perfectly, regardless if triggered via gui or via device (simulation: on)
TS130Fnow behaves other (simulation on or off, both):
When triggering via gui, it looks perfect, switch is triggered and gui show continuous changing numbers and keeps the respective number where stopped.
When triggering via the device, the gui doesn’t jump any longer to 50% when stopped, but jumps to 100% (and open), when ‘open’ and then ‘stop’ is pressed and jumps to 0% (and closed) when ‘closed’ and the ‘stop’ is pressed. And having it only let 2-3 sec. ‘run’, it would definitly not be in one of the end-positions.
Maybe Pimatic-Raspee might need two different devices, as TS130F already worked well?
It has (by default and not adjustable via the deconz gui, as the other device) a very long rollertime, something ~1 min.
The 2-3 sec I mentioned below I triggered manually .
I tested the new version on a QS-Zigbee-C01 Zigbee Curtain Module.
Thats a TS130F type of device. The default rollertime is 12-15 seconds.
That interferes with the simulated rollertime, so i adjusted it to ~ 25 seconds
Manual stopping an up or down action after 2-3 seconds, leans heavily on a correct rollertime. Because the zigbee device uses the rollertime to calculate the position.
My test results:
In simulated mode, cover fully closed. when I push the fysical open button, the slider and position stay at 0. But when pushing the open button again, the shutter stops and the position of that moment is visible in the gui (slider and position)
@bertreb said in Release pimatic-raspbee@0.1.6:
TS130F t
I tested again and firstly checked the rollertime by stopwatch. It is really >1 min. and I didn’t change it, as trying to do so, deconz snet me back an error.
I let it move ‘down’ until it toggeled itself back to ‘stop’.
Knowing now the time, I changed the rollertime of the raspbee device to 100.
Then pressed ‘open’, waited 10 sec. (stopwatch) and then pressed ‘stop’ (both on the device).
But the result stays the same, as explained below. When pressing ‘open’ the gui is directly pushed to 100% and ‘opend’.
I’m sorry, that’s how it behaves.
OMG, I fear changed the names of the devices.
Let me double-check …
ok, verified it additionally via Phoscon,
I’m sorry, I was talking here about TS0302 and not TS130F.
Means:
TS130F works perfectly
TS0302 has the problems with the values in the gui.
I’m really sorry!
yep - shall I use the former version?
correct!
Ok, thats a tricky problem.
The shutter isn’t sending any position info except lift: 0% (opened), 50% (stop) or 100% (closed)
And I don’t know at what moment the 0% or 100% is send.
But i made a small change to raspbee.coffee. Can you check if this is working for the TS0302?
Test with simulation on/off, but no change.
Is it now that tricky as the two shutters behave that differently?
… as this typ was the first one you implemented and it already worked!?