Thorgal789 wrote: ↑Saturday 25 March 2023 11:51
But making a small PR with only 1 field have more chance to be valided, if I have understand you need "state/LoadEstimateOnThisRadiator" ?
Yes, this would be the one which I now catch with the PM2.5. But currently I also use
- config/duration, which could be config/LoadRadiatorRoomMean and
- config/usertest, which could be config/LoadBalancingEnable.
To get the problems with the plugin solved sustainable for me all three should be implemented into deconz API / DDF enviroment.
Thorgal789 wrote: ↑Saturday 25 March 2023 11:51
It's realy usefull for you ? because on my side I don't see what to do with this value.
This is part of a feature that prevents that only one radiator in a room with more than one taking the whole heating load. This means, it could happen that one radiator turns could but the other heats with 99%. From my point of view this is very inefficient.
With LoadEstimateOnThisRadiator value from each radiator a mean load is calculated and played back to each radiator with LoadRadiatorRoomMean.
Thorgal789 wrote: ↑Saturday 25 March 2023 11:51
Honnestly I think we can try the third solution and if they don't validate the PR, I will make the second.
You can make the second solution waiting for something official to have good temperature.
As a quick solution I just picked the fifth option and went back to plugin version 1.0.26
And yes, I would be very happy if you can make a official PR for the three items above.
As we are in dicussion anyway. It would be also pretty usefull, if the state/valve attribute would be implemeted into the plugin to get a domoticz device and this may also contains the solution for the current problem anyway.
For the PR we can try but now it's 3 fields to add ^^, but can try. Can you check the code https://github.com/Smanar/deconz-rest-p ... 7022a8e8b2
I don't think you are able to test the state one, but the config ones can be tested without editing c++ code.
I haven't set refresh.interval, IDK if it's a good idea, I don't want deconz spam the device for nothing, I can to set a 24h reports, what are you using on your side for test ? (And need to add them to the DDF too, idk how look your DDF ATM)
BTW, the beta branch of the domoticz plugin was updated, I think it will solve your issue, just need to switch to beta branch.
For the state/valve, it will make one more widget, and IDK what you can do with it ? Users generaly set a heatpoint and take a look on temperature return, if the valve is open or not .....
I will see if I can test the code as soon as possible, but I need some time I think.
If I‘m not wrong I haven’t set a refresh interval. It is then the default if there is a default. I can share my DDF when I tested the code.
Why always asking what to do with such value? I‘m a little bit nerdy and want to see what’s going on with the radiator. For example I see the possibility to optimize the heating system temperature when I know how much the valves are open. With your argument it could also said that we don‘t need the temperature reading because we will notice if it’s too cold or too hot
But yes, it’s easy to just get the data with a little script and put them into devices.
Not relay need, have modified the file with a 24h interval, like that you will have 1 request at start to have the first value, and we can be sure the device will never be spammed.
You need to put one for the "state/loadestimateonthisradiator" (pm2.5 for you) but this one need be in the DDF so not specific to this PR.
Just tell me if the 2 "config item" seem good for you for I make the PR and we can cross finger.
Why always asking what to do with such value? I‘m a little bit nerdy and want to see what’s going on with the radiator. For example I see the possibility to optimize the heating system temperature when I know how much the valves are open. With your argument it could also said that we don‘t need the temperature reading because we will notice if it’s too cold or too hot
Yeah but the problem is the defaut working mode is for all users, so it mean if I add the state/valve, all users will have it, an it will make lot of devices. For state/tension, after a long negotiation I have finnaly created a special setting to enable or disable them, but state/valve you have the first one that are asking for it ^^
I checked your PR without testing it. Sorry no time atm.
But I think with the config/loadradiatorroommean you did a copy paste mistake.
It is not Boolean, it should be a int16 and the description doesn’t fit properly. But all addresses seems to be good.
In addition it seems that this value has only write access according to the Danfoss firmware documentation. With my „duration-item“- solution I often get values -8000, only just after writing the value I get the correct value back.
This my needs further testing. I don‘t understand the logic behind writing but could not reading.
We are doing same for "state/loadestimateonthisradiator" and "config/loadbalancingenable" but I m realy lighter than you for "config/loadradiatorroommean" ^^
Thorgal789 wrote: ↑Thursday 06 April 2023 17:52
We are doing same for "state/loadestimateonthisradiator" and "config/loadbalancingenable" but I m realy lighter than you for "config/loadradiatorroommean" ^^
What do you mean with that? How your DDF looks like?
It was just a quick `n` dirty try and error to build this DDF so I never really understood what all this parameters do.
Hello, what is your deconz version ?
If all the rest is working (it's the startup part, so I think you are stucked, but the plugin ask previously for config/light/sensor), it's probably because your version don't support yet the alarmsystem. You can try this url in a browser you will have this error "method, GET, not available for resource, /alarmsystems".
As solution you can update your deconz version, or if you want to keep an old one, I can give you a modification to done on the python script but this exist since july 2021.
Thorgal789 wrote: ↑Sunday 23 July 2023 9:26
Hello, what is your deconz version ?
If all the rest is working (it's the startup part, so I think you are stucked, but the plugin ask previously for config/light/sensor), it's probably because your version don't support yet the alarmsystem. You can try this url in a browser you will have this error "method, GET, not available for resource, /alarmsystems".
As solution you can update your deconz version, or if you want to keep an old one, I can give you a modification to done on the python script but this exist since july 2021.
I hope you will not have issue, after a 1 year jump version ^^.
If you have made a backup and want to use an old version, there is no problem, you can too use old plugin version if you don't need last feature, or if you know a little python the plugin is easy to customise.
I m shy to use last version too, don't want to break something, but recents versions have some usefull stuff, like the support for zigbee keypad using the alarmsystems endpoint for exemple and for the moment few bad return for the last deconz official one (except for sonoff sensor, corrective WIP).
Hi all, I cannot find a solution in this tread or other fora and would like to know how I can solve this?
I'm using RapsberryPI 3B with bookworm and Conbee-II.
Phoscon and Conbee are working correctly and even I can use the information in Domoticz with a old version of the Deconz plugin.
Version: Deconz/Phoscon 2.29.2-beta, Python3.11, Domoticz 2025.1 (build 16576),
I just created a fully new install but still the same errors in the log:
Your solution is in the code. If this is the case, many users should have the same problem because I use the original code.
So if it should be corrected, I assume Smanar or somebody from the develop team would like to fix it.
