Replies: 3 comments 5 replies
-
Hi @alevike Thank you for this idea, and I must say, you are not the first one requesting this. I originally did not plan to add this kind of controllers, as I don't own one, and don't need it myself which makes very difficult to guess API calls and responses, but the work you did above is bit motivating. I already learned that other controllers' information is delivered via "tiles" object and what you did in the pdf is very helpful, but it's not fully correct. There is no sense to do mapping between tile id and widget, as every each user will have probably different ids for their widgets setup. Therefore if you are willing to do some more work to support this integration, you could redo the mapping, but based on following?
I think that type and description describes main widget type, and later txtId and iconId presents subtypes, for example: type: 11 can have subtype widgets described with different name (txtId) and icon (iconId), like feeder and pumps. Moreover, if you can check if iconId differ for different workingStatuses and do the mapping for those as well. When we have such mappings this will be huge step forward. I did contact producer asking for documentation, but so far no success with that, therefore we need to do it ourselves. Cheers, Mariusz |
Beta Was this translation helpful? Give feedback.
-
Hello Mariusz,
I've tried to redo the mapping as requested. I still think that there are
more than one pattern for widget type. In some cases the textId and the
iconId are not present...
Please find attached the updated mapping with more details
Regards,
Levi
…On Tue, Jan 12, 2021 at 12:19 AM Mariusz Ostoja-Świerczyński < ***@***.***> wrote:
Hi @alevike <https://github.com/alevike>
Thank you for this idea, and I must say, you are not the first one
requesting this. I originally did not plan to add this kind of controllers,
as I don't own one, and don't need it myself which makes very difficult to
guess API calls and responses, but the work you did above is bit
motivating. I already learned that other controllers' information is
delivered via "tiles" object and what you did in the pdf is very helpful,
but it's not fully correct. There is no sense to do mapping between tile id
and widget, as every each user will have probably different ids for their
widgets setup.
Therefore if you are willing to do some more work to support this
integration, you could redo the mapping, but based on following?
- type
- description
- txtId
- iconId
- widget screenshot
I think that type and description describes main widget type, and later
txtId and iconId presents subtypes, for example:
type: 11
description: Relay
can have subtype widgets described with different name (txtId) and icon
(iconId), like feeder and pumps. Moreover, if you can check if iconId
differ for different workingStatuses and do the mapping for those as well.
When we have such mappings this will be huge step forward. I did contact
producer asking for documentation, but so far no success with that,
therefore we need to do it ourselves.
Cheers, Mariusz
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOQQY7HZLMNIEXNSMA4KHVLSZN2ORANCNFSM4V2KKQTQ>
.
|
Beta Was this translation helpful? Give feedback.
-
Hello Marius, I had some issues generated by the defined refresh value for this integration. It looks like Tech has some limitations for this option. If the state is refreshed on each 30Sec, the controller is "blocked" on emodul.eu - receiving error 502, 501 after a time. Alos the controller become offline on emodul.eu. I've try to reduce the refresh rate to once/minute. Seems to resolve the problem - didn't had any issue after. Regards, |
Beta Was this translation helpful? Give feedback.
-
Hello,
It looks promising, i have a OPOP: ST-581v9 Premium unit - it is a pellet boiler - if you're interested to implement the support for this one i will gladly support you..
LE: managed to connect/authenticate to the controller via Postman and gather some info.
LE2: identified each id with the corresponding widget. Let me know if it make sense to move forward with the investigation.
LE3: moved topic form issues to discussions.
Mapping attached:
opop_mapping.pdf
Beta Was this translation helpful? Give feedback.
All reactions