Release pimatic-raspbee@0.1.6

---

ok, image is already copying.
I will use then the api from dev, as this works, but maybe test also from prod, to verify the issue.

Hi @bertreb, sorry for the longer break, but had some other things to tackle in the meantime and thus wasn’t able to continue with the problem search with the TS0302.

Yesterday now the second shutter switch device of that type arrived and that is now kind of unbelievable!
It looks 100% the same and also the printing on it is 100% the same.
I thought, well let it quickly join my prod environment to verify the issue which we exchanged about here regarding my first of these devices and:

1. Simply from outside, the LEDs (on the front) behave a bit other - which I could live with …, but
2. It was discovered as a TS130F (!), as said same device with same printings on it!

I have no clue what these Chinese folks are doing there!?
However in general it works perfectly, only have to check if I will be able to change the roller-time via deconz gui, as 8sec. might be a bit too short …

Happy Easter

Hi again, I was now just starting to continue the search for the issue with the TS302…
But while already booting the 2nd dev/test system, I did again a quick check on my prod system, as the device anyhow still was paired to it, … and again unbelivable(!), the issue has gone!
I’m able now to steer it propperly via the pimatic gui as well as form the device, which changes then the values in the gui.
I didn’t change anything at all in the setup. I have no clue how this comes now…!?

However, I guess I will go now and mount the devices into the respective walls and test them in daily life.
A 3rd one is already ordered, let us see (and maybe laugh), if a TS302 or a TS130F will be delivered…

PS.
The problem with the missing sensor data of the Blitz plug still continues to exist and is further on discussed on git …

Hi @bertreb, a question to you regarding the plug value measurement:
I was now able to connect the one plug without measurements again propperly to Phoscon / deCONZ. I can see the values via the deCONZ gui and also that they change there, according to the load I have on it. That was really tricky, but in the end it worked.
My point is now, that still raspbee seems not capturing the sensor IDs, when discovering the device (as RaspbeeSmartSwitch). The device is there, incl. ID, but w/o the sensor IDs, which have been automatically discovered for the other two plugs.
Is there any possibility/methodology, to understand this mapping manually?
E. g. by converting the respective ID numbers from the deCONZ gui and simply put them in manually into the config.json!?

Hi, if the sensors IDs are not discovered, the values are probably also not sent by Deconz.
You can add sensor id’s manually. The values are the same as used in deconz/phoscon.

@bertreb said in Release pimatic-raspbee@0.1.6:

The values are the same as used in deconz/phoscon.

Hi, I guess you mentioned something like this somewhen befor, but in Phoscon I cannot find any IDs at all and in deCONZ gui, the IDs seems beeing in hex or something else!?

I have no clue how to convert them to the decimal values which are used by Raspbee?

I dont know the conversion.
You could compare discovered sensor id’s with the phoscon values and determine the conversion

@bertreb said in Release pimatic-raspbee@0.1.6:

You could compare discovered sensor id’s with the phoscon values and determine the conversion

Hmhm, but that is exactly the problem, in Phoscon aren’t any ids.
So if they are in, could you provide a hint where I can find them?

I mean other devices with discovered ids

I got your point, but I might be too blind to find the ids in the web-frontend.
I never saw ids or other parameters in Phoscon.

The screenshot above with the hex ids, but then from a device with in raspbee discovered sensor ids

@bertreb said in Release pimatic-raspbee@0.1.6:

he screenshot above with the hex ids,

ahh! the screen shoot is from the deCONZ gui, not from the Phoscon app
I will check this then directly in deCONZ …

Thanks for now!

That didn’t lead to a result.
All the IDs and the values behind are completely the same in deconz amongst the three plugs. They look like triplets.

… I close for today and will test a complete new pairing tomorrow.

You can configure the sensor ID manually, but if the API isnt providing the sensor / data you wont get any info.
You can check if the sensor data of the plug is available with the browser url "http://<ip address deconz>:<port>/api/<api key>/sensors"
Check if the plug is in the list. If its in the list, the sensor ID is the key value of the sensor. Every sensor record starts with “<sensor ID >”:{“config”: …
If its not in the list, adding it manually doesn’t help, the problem is in Deconz.

@bertreb said in Release pimatic-raspbee@0.1.6:

If its not in the list, adding it manually doesn’t help, the problem is in Deconz.

Yep, I meanwhile did a another test while using the deconz integration in my ioBroker instance and there I got the same/similiar issues with this device.
(https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3788)
Good thing there was, that ioBroker clearly shows device’s and sensor’s IDs directly in the web frontend in the objects section. Here I could verify (additionally), that what is delivered from deCONZ is waste, allthough in the deCONZ gui the values are shown propperly. I guess it’s a problem with the rest-api, or with the general deconz-pairing of these devices.
But at least only, when this type of device is paired a second time and also not necessarily to the same deconz. Maybe it would have to be reset via the original Tuya/Blitzwolf Gateway to work propperly in another environment!?

Hi again,
at least the one nasty plug is now also running propperly incl. all measurements (voltage, current, power, consumption).
I never saw such a wondering behaviour with a ZigBee device, but in the end it worked.
If one might run into similiar issues with the Tuya/Blitzwolf BW-SHP13, please have a look here:
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3788

One have to scroll down to the very bottom…

I refreshed my deconz to variant 2.07.01/8.12.2020 and the firmware to adaptation 26660700.

Since I did that I get Bad solicitation each time I attempt to control my ikea blinds.

Every one of my controllers and movement sensors are not revealing their status.

The clever thing is, the ikea dazzle reports when I physically press the catch to open or close it on the blind,but in the event that I press anything in pimatic, I simply get terrible solicitation brief. http://liverpoolsmanandvanservice.co.uk/

Is it possible to connect two raspbee/ deconz instances to Pimatic. In Dmoticz it is, but since Pimatic is (still) my primary system, it would be nice if this is possible. Both deconz controllers are accessible in my home network. One is in the house and one in the barn, which is too far away to create a mesh network for one deconz controller.