Release pimatic-raspbee@0.1.6

---

These are messages from the devices and not the result of the sensor or light config request.
You need to search for 'sensor list … or 'light list … or mail me the log

… that was the reason why I tested it on the kitchen-tablet, as there I definetly didn’t load the Pimatic frontend after the yesterday’s changes, as there a VIS frontend is running - you might remember to that, as I mentioned it already in one of our chats somewhere end of last year …

@bertreb said in Release pimatic-raspbee@0.1.6:

'sensor list … or 'light list

ahhh, please stay patient with me , now I have it
But that might be the problem, as there isn’t anything in the sensor list regarding ID '5’
But still in the light list:

17:49:15.837 [pimatic-raspbee-plus] debug:>  '5':
17:49:15.837 [pimatic-raspbee-plus] debug:>   { etag: '216db3ce4f7265fa6f6608b404275462',
17:49:15.837 [pimatic-raspbee-plus] debug:>     hascolor: false,
17:49:15.837 [pimatic-raspbee-plus] debug:>     lastannounced: '2021-03-19T23:49:19Z',
17:49:15.837 [pimatic-raspbee-plus] debug:>     lastseen: '2021-03-20T16:48Z',
17:49:15.837 [pimatic-raspbee-plus] debug:>     manufacturername: '_TZ3000_g5xawfcq',
17:49:15.837 [pimatic-raspbee-plus] debug:>     modelid: 'TS0121',
17:49:15.837 [pimatic-raspbee-plus] debug:>     name: 'BlitzPlug01',
17:49:15.837 [pimatic-raspbee-plus] debug:>     state: { alert: 'none', on: false, reachable: true },
17:49:15.837 [pimatic-raspbee-plus] debug:>     swversion: null,
17:49:15.837 [pimatic-raspbee-plus] debug:>     type: 'Smart plug',
17:49:15.837 [pimatic-raspbee-plus] debug:>     uniqueid: '60:a4:23:ff:fe:5e:2a:9f-01' },

I guess that explains why I’m able to switch the plug, but do not get any data…?

If there’s no sensor data from the Blitz, there’s nothing in the device config and nothing in the Gui
The uniqueid of the Blitz starts with 60:a4:23:ff:fe:5e:2a:9f, you can check in the log if there’s any sensor starting with this uniqueid.

@bertreb said in Release pimatic-raspbee@0.1.6:

60:a4:23:ff:fe:5e:2a:9f

ok, went through the entire log file, but only the plug is sending with this ID.

I’m sorry I have to stop here, as my daughter asked me to help here on a little emergency case - nothing real bad, but as live is.

Will come back, but not today …

Did you try pimatic-raspbee-plus on your dev system?
You can install it separately from pimatic-raspbee and because it uses the same Deconz, it could help find issues.

Hi @bertreb, just found an hour to continue here.
and yes, for sure all the stuff was already running on my dev system, incl. raspbee-plus and all devices, shutters, warning and smartplug. Otherwise I would never have tried to bring it to prod, incl. raspbee-plus.

I additionally verified the deconz and the conbee stick versions btw. dev and prod and that also cannot be the problem.
For deconz the versions are exactly the same and the version on the stick of the prod system even is a bit newer then on the dev stick.

I now just used a fresh .log file to do the discovery again, which I will send you in parallel via mail. Maybe this helps.

After that I thought that it might be a good idea to do the discovery also again on my test system, to compare the discovery of it’s.log file with the one from the prod system, but …
Booting the dev system now after a view days beeing off, I wasn’t able to get Pimatic, as well as deconz, back to life and also my XRDP client has problems.
You will remember, that on this Raspi3B I already had some SD card issues ~3 weeks ago and if I remember right, that was the same Raspi3B I had the issues roughly a year ago. Thus I fear, that this little thing is a special kind of SD card killer … , … as that ever only seems happening at him and not at all on all of my other Raspis.

However, I still have another 3B here and will set up a new dev system the next days. But that will take a while, as I do have to tackle currently some other stuff here in parallel.

If you might find something in the .log file, for sure I can contiune testing on my prod system. The frontend errors didn’t come back yet.

Hi, i received the log and checked for sensor info from the Blitz SmartPlug.
There’s no sensor data. So that is consistent with the discovery.

The question now is, does Deconz send sensor data.
You can check that with a browser and the url 'http://<deconz ip>:<deconz port>/api/<api key>/sensors’
In the returned json data, you should check for the Blitz SmartPlug.
If the the sensor data is in the JSON data then the problem is in the plugin else there’s an issue in Deconz.
Let me know the result or send me the JSON data

@bertreb said in Release pimatic-raspbee@0.1.6:

The question now is, does Deconz send sensor data.

Hi @bertreb, I fear that looks bad.
I have now again a dev system up and runing with raspbee-plus.
I connected, after having done again a factory reset with the BlitzPlug via the Deconz-gui, the device again to Pimatic.One can switch it on and off, but still no data is comming in.
I tested then with your command and that doesn’t look good. In the respective json there is no data at all from the Plug, whereas the data is definetly in the deconz-gui, as I could check before. Now I have the fear, that by already resetting it to factory settings earlier, I might have damaged something.
If you have no other idea, we will have to wait for two new ones of them, which I already ordered when we have been at the status alraedy that everything was working propperly.
I will close for today …

Hi, when the data is in the Deconz Gui the SmartPLug should be ok.
Is the data updated in the gui?
The problem seems then Deconz not sending that data via the api.

Hi, yes in deCONZ (gui) one can see that the data (current, voltage, power) is updated.
I will check the entire config and versions again and will now also test the shutter devices, wish I didn‘t find the time for yet.

Hi again @bertreb, I updated deconz on my prod system now additionally on to the freshly arrived new stable version (2.10.04 / 14.3.2021). The stick’s firmware is also up to date (26680700).
The siren (RaspBeeWarning) and the shutter device TS130F (RaspBeeCover) are working propperly

But still the other shutter device (TS0302) and the BlitzPlug (RaspBeeSmartSwitch) do have problems.

Steering the TS0302 device via it’s own buttons, propperly triggers the gui, but I cannot steer it the other way around, by using the gui.Here it is interesting, that the device works propperly on my newly set up dev system, but still not an my prod system.

Both systems are running on raspbian buster, and do have Pimatic/RaspBeePlus and deCONZ on them.
The stick firmware is a bit newer on the prod system, but which should mean, that it should run better on this and not more bad. Still the node versions of the systems are definitly not the same.
prod node: v10.23.3
dev node: v12.21.0
But can this be the reason? - I guess not.

The BlitzPlug still has the problem that no data is shown/received any longer. This behavior is same on my prod system, as well as on dev system.

Do you have any further ideas?

Hi, a lot of work done with good progress. Two remarks on the remaining 2 issues in reversed order.

• please do the api check again on the BlizPlug sensor data. If the api isn’t returning sensor json data for the BlizPlug, i can’t fix it in the plugin.
• If the TS0302 is working on the dev but not on the prod system, the problem seems to be in the different system setup. Thats also something i can’t solve in the plugin.
  You could try to use a third rpi with pimatic. Install raspbee plus and configure it.

I would keep the node version to 10.23.3. If node 12.21.0 compiles, thats ok. I don’t use 12.x and don’t test plugins with it.
Is there a reason for you to use node 12.21.0?

Hi,
regarding the api check, I did it now again. But as stated already somewhere below, the BlitzPlug doesn’t show up in the json at all.
Here I will check further parameters of the device via the deCONZ gui, if maybe something has to be adjsuted there. On the other I hand, I hopt that the other two of them, which I already ordered, will be delivered soon. Maybe trying an other one will show, if it is something with the devices itself.

Regarding the TS0302 I will try to check further on parameters and so on. Setting up a 3rd PI, I don’t know as this would become the same as my current dev system!? … and the node versions 12.x came along ‘automatically’, for sure I could downgrade to 10.23.3 and then see, if that changes something.

I will come back again the next days, not more today …

Ok, succes with the next steps.
Btw if you install buster lite, as far as i know node/npm is not installed automatically

Amazing!!!
After a lengthy search for problems with the SHP13/TS0121 plug, I found this on github:
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3788

It seems to be, that the issue of getting no values/measurements any longer from the deconz api, always happens when the plug is paired again after it’s first pairing. Several related further issues have been opened on git about this, which shows that I’m not alone here

Then let’s wait and see…

I will now continue with the shutter problem …

I last question this evening, maybe also to answer tomorrow …

I just reseted the TS0302 and paired it again with my prod Pimatic.
What I see now is, that I can use the ‘stop’ button in the raspbee gui to switch the device back from the ‘open’ or ‘close’ position. Any clue about this, as there is a reaction in general.?

As said, in my dev environment all works propperly, regardless if rasbee-plus steers the device, or the other way round.
And the only two differences in the setups seems to be the node/npm version and the fact that one is a Raspi3 (dev) and the other is a Raspi4 (prod), as I additionally now downgraded the ConBee stick firmware on prod to the same version as I do have on dev.

I will try to find (tomorrow) if and what is send from raspbee-plus…

Downgraded now node/npm on the dev system to v10.24.0/v6.14.11, which is then similiar to prod with v10.23.3/v6.14.11.

But also by this I wasn’t able to reproduce the problem with the TS0302 on the dev system.
There it simply works, but still not on the prod system. And really all versions of everything are now the same

I also checked again what is send by comparing respective details of both logs (dev/prod), but that all looks 100% equal, on basis of raspbee-plus.

Now I really do have no further clue and only see two additional options:

1. Search on git for a similiar pairing problem as the plug device also has.
2. Wait for the delivery of the next device and firstly pair it with my prod system.

Can you check on both systems if the node_modules directories in the pimatic-raspbee-plus directory, are the same?