Closed oywino closed 3 years ago
I think, the problem is, that node-red-contrib-deconz doesn't pick up all types such as ZHAThermostat from Deconz.
I am currently running Openhab 2 server with Deconz binding installed to pick up all unsupported devices from the Deconz REST API: https://www.openhab.org/addons/bindings/deconz/
Then use node-red-contrib-openhab2 to forward them in NodeRED.
I think, the problem is, that node-red-contrib-deconz doesn't pick up all types such as ZHAThermostat from Deconz.
And you are right, of course. But the strange thing is that Dresden-Elektronik's own solution (Phoscon) also fails to pick up ZHAThermostats. The author of node-red-contrib-deconz insists that is the reason why his solution also fails to pick up these devices. Perhaps he need to redesign his solution to bypass Phoscon and fetch directly from deCONZ (like OpenHAB does?). But if so, I do not have what it takes to persuade him to the effort. Secondly, it doesn't solve the problem of Phoscon failing to pick up ZHAThermostats also. That's the basics for this [DEVICE REQUEST]
Can you tell me the modelid?
I am not sure exactly because ELKO does not use the term "Model-ID". But the attribute modelid as returned from the REST-API is Super TR
Below is what else I found in their product documentation:
ELKO Super Termostat / Regulator Article Numbers: RS: 5287 PH Plus: 5296 PH 5303 ALU 5304 SO
Apparently it comes in 4 different versions. The main difference is the material design (White Plastic/Aluminum, Black, etc) They also in another product leaflet denote the device like this:
RS Elko Super TR PH Elnummer: 5491616 Varenummer: EKO05287 EAN: 7020160528711
I hope this helps.
And you are right, of course. But the strange thing is that Dresden-Elektronik's own solution (Phoscon) also fails to pick up ZHAThermostats. The author of node-red-contrib-deconz insists that is the reason why his solution also fails to pick up these devices.
@oywino Sorry, but this is just rubbish. Phoscon consumes the API, it's just a client, but whitelists and enriches what is exposed/available in the webapp.
I could rather imagine node red has some kind of predefined pattern for thermostats where the Super TR doesn't fit in. It has 2-3 extra parameters being unique to the device.
Well, I generally avoid characterizing other people's statements as "rubbish", but the fact is that after pairing the Thermostat using Phoscon, it does show up in deCONZ, but it's nowhere to be found any trace of it in neither Phoscon nor the "old" WebApp.
Well, it is what it is and "rubbish" isn't such a harsch word at all. I tend to be very direct at times, especially when forceful words as "insist" are used. Anyway, we're not here to discuss lingual details, I assume.
... but the fact is that after pairing the Thermostat using Phoscon, it does show up in deCONZ, but it's nowhere to be found any trace of it in neither Phoscon nor the "old" WebApp.
And that is perfectly fine when a device has been supported "just" from the API and does not (yet) fall into any common recognition patterns or is not whilelisted explicitly. Again, Phoscon and the old WebApp are API clients, consuming it. Making them visible there will leave the REST API untouched. Therefore, the given statement is incorrect.
Ok, thanks for your understanding. So - in essence - what you are saying is that my [DEVICE REQUEST] application over in the phoscon-app-beta repository serves no purpose at all in order to solve this problem?
Well, it solved nothing regarding to what you experience on the node red end. However, if @YKO-de adds it to Phoscon, it will be visible there.
Well, according the author of the NodeRED deCONZ Pallette, full functionality depends on the device being visible in Phoscon. So let's hope that @YKO-de will find the time to add it to Phoscon - and then we'll see if it helps or not. If not, I can continue to work with the author of the Pallette.
The device should be visible in the app. Can you please try it without a third-party provider at phoscon.com/pwabeta?
Hi @YKO-de - Thanks for participating. I'm not sure what you mean by "a third party provider" ? Everyone in this forum agrees that the ELKO Super TR is not visible in Phoscon after successfully pairing it. Are you saying it should be ??
I meant directly via the browser. Many people use Home Assistant, for example.
Yes I actually already support the device
Okay. I think I've figured out what the problem is. Should be fixed in the next release.
Excellent! Is that now - desember 15th (or January 15) ? 😊
I'll have to ask. Possibly in December. But in January at the latest.
@YKO-de, I've upgraded to 2.0.8 but the ELKO Thermostat still doesn't show up in Phoscon.
Hurra! After upgrading to deConz v2.0.9 the ELKO Thermostat finally showed up in Phoscon:
As there hasn't been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.
Even though things seems to work as it should, I keep getting log entries suggesting something is still missing:
13:28:44:803 [INFO] - No button map for: Super TR, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0201, command: 0x0A, payload: 170428E4, zclSeq: 134
13:28:44:804 ZCL attribute report 0x000D6F000E9DC646 for cluster: 0x0201, ep: 0x01, frame control: 0x08, mfcode: 0x0000
This device is now fully operational and supported in deCONZ 2.05.88 The device is paired using Phoscon, but does not show up in the Phoscon Sensor listing despite successful paring. As a result, it is also not properly listed in other third party integrations such as node-red-contrib-deconz which is a Pallette add-on for NodeRED.