Release pimatic-raspbee@0.1.6

---

@bertreb said in Release pimatic-raspbee@0.1.6:

modules directories in the pimatic-raspbee-plus directory, are the same?

prod:

dev:

Wondering that '.js ’ is missing on dev…? … but thinking about, may I have to delete it on prod and then restart?

By also checking the device entires in both config.json files, I recocnized, that on the prod the device has a 2-digit (24) ID and on the dev a 1-digit (5) ID. But it would be really stupid if such would be the problem.

Thanks, you can delete the .js directory anyway. On restart this directory is created again and it ensures that all .coffee files are compiled.

I was referring to the contant of both node_modules directories and if the content is the same.

yep I know, as I did this a couple of times while you where developing raspbee-plus.
Gave it a try now, but it doesn’t help …

That is really kind of a miracle, as sending the commands (up/stop/down) directly from the deconz-gui, it works and as said, also the log-entries in pimatic look 100% the same btw dev and prod …

Did you tried for this device the 3th system test (a 3th rpi with pimatic)
Because if 2 ‘equal’ systems do behave differently, you can use a 3th judge system to identify the faulty system or reproduce on purpose the fault

I could, but then I would have to use my ‘SD-card killer’ Raspi3B - I guess you remember

But as this normaly only happens after a couple of reboots, I could give it a try, sure.
I guess for this it will work.

I will come back then

And to test the plugin without the gui action part, you could use curl api calls for up, stop and down.

ok, something to be happy
‘The’ RaspBeeSmartSwitch now works on prod, as (thanks very fast post service) two further ones arrived today and by pairing it now directly with the prod deconz, it works!
Interesting is, that one first has to do a pairing of it as light and then additionally as a sensor (in Phoscon), by having a load on it and switching on/off. Allthough it is afterwards still only visible as light, then Pimatic discovers, besides the device ID, also the sensor IDs:

And regarding your hint to use the curl commands (thanks!), with these the shutter switch can be steered (open/stop/close), … thus, why the hell not by the respective RaspBee device…?

Ok, good news.
You used the curl commands on the device that didn’t work via the gui?

@bertreb said in Release pimatic-raspbee@0.1.6:

used the curl commands on the device that didn’t work via the gui?

Yep, the TS0302 on the prod Pimatic.

Can you mail me the files: template-raspbee.coffee and template-raspbee.jade?
They are in the /app directory on the system the gui is failing.

@bertreb said in Release pimatic-raspbee@0.1.6:

template-raspbee.coffee

mail is out, but I have to run now for dinner and afterwards with the dog
will be back at ~20:30h

Can you to summarise, post again the problem with the TS0302?
And are the device configs on prod and dev exactly the same? (incl grayed out defaults)

sure, relatively simple:

• using the device’s buttons triggers the RaspBeeCover gui buttons propperly (gui buttons, slider and open percentages)
• using the RaspBeeCover gui’s buttons do change the open percentages in the gui and the slider, but do NOT trigger the device’s buttons, resp. by this in the end the shutter. Exception here is: When the device is already on open or close, then the stop button of the gui triggers propperly the stop button/function on the device.

This issue I have only when having the TS0302 connected on my prod system. On the dev system all works propperly in both steering-directions.
And wondering now in addition is, that I can steer ‘open/stop/close’ on the prod system proppery by the curl commands, despite the fact, that the same are not working by the raspbee-plus device.
And the same means, that I copied the respective commands (e. g. curl -X PUT … /lights/25/state -d ‘{“open”:true}’ -s) from the log file of the respective RaspBeeCover device.

In addition: The TS130F does not have this problem.

OK, can you also mail the file raspbee-plus.coffee (in directory pimatic-raspbee-plus)

overlooked your second point below, but yes, the device configs are also 100% the same

I see no differences in the files you sent.
The logical next step is testing raspbee-plus and TS0302 on a 3rd system.

I feared that you will come back with this.

Ok then I will start now to set up a third system, meanwhile I’m getting a kind of routine with this… .

… but to add, I have to use the ConBee stick form my current dev system, as for sure I do not have two spare sticks here …

You don’t have to use the ConBee stick. You can use in the plugin, the Deconz api from your dev system.

hmhm, sure you’re right, but thinking about the working curl commands and the not working gui, I guess via the same api…!?
Would a test in that way (using the dev api) then be really meaningfull?

Yes, its meaningful because the problem seems to be around the gui and not Deconz.
If you use in the 3rd system the Deconz api from the system that works (prod i believe). This will be a good test setup.
If the 3rd systems works perfectly you should switch the api to the other system and test what happens.