Ignoring data
pitenge opened this issue · comments
I have successfully installed the Resol binding on OpenHABian v.2.3.0.
The BridgeVbusLAN adapter together with two THINGS (SKSR_1_2_3 and SKSC3-HC1) appears automatically and seems to be working fine. All values also seems to be updating correctly.
My problem is that there are two more "devices" in my system not showing as THINGS.
A screenshot from the RESOL ServiceCenter software shows the "devices" that are missing:
A screenshot of the log shows that data from the two devices is being ignored:
Do you know why this is happening? Any way to fix this?
I am especially interested in the temperature values from the MSR65.
Thanks for reporting.
Can you tell a bit more about the devices? Are they "branded MX and EM devices" or what are the differences? Why they are ignored is easy to explain: I have a setup with an MX and an EM, and the MX receives the EM data and broadcasts it to the "DFA", therefore I assumed that this will be the case for all such setups and I only create things and channels for packages sent to address 0x10. If the sensor values are not somewhere in the "SKSR 1/2/3" or "SKSC3 [HK1]" things we obviously have to add more "receivers".
@danielwippermann do you have an idea how to decide whether the data transmitted to a device different from 0x10 might be interesting? Or should we just add a configuration "publish ALL devices" - which will put all data into openhab?
The channel "System time2" is also interesting, the datatype seems to be wrong. Do you know what this is compared to "System time" (without the 2 suffix)? Can you extract some information in Service Center?
this is BTW already present in #13 - which I will close now, in favor of this one...
Thanks for the quick response.
The two physical devices I have in my system is branded SONNENKRAFT controllers.
SKSC3 is a System Controller, probably like the DeltaSol E (from 2009)
SKSCHK1 is a Heating Circuit controller connected to the SKSC3. I'm not sure which Resol model this actually is. The values from the SKSCHK1 (MSR65) seems to be adressed to the SKSC3, and not being broadcasted by the SKSC3.
The "System time2" differs from the "System time" by adding the weekday. I think this is the only difference.
The feature that the controller aggregates all module information and retransmits it to the DFA is a rather new function. The SKSC3 does not yet implement such a feature, as most other controllers won't. The MX is more the exception than the rule here.
That said: an option to include all packets as things would definitely make sense to support more legacy controllers.
And yes, the "System time 2" was added later in development to include the weekday in addition to the time itself. It uses the "WeekTime" formatter in the library.
Dear Ramack.
Do you have any information if this issue will be fixed in a near future update of the binding?
I'm currently working on a project where I need the temperature values from the MSR65 (outside temperature, tank temperature and flow temperature of the heating circuit) to be used as conditions for other functions. Unfortunately, I'm not capable of making the necessary adjustments to the binding myself. It would be really nice to know when I could expect a fix to be available.
Best regards.
Thanks for pushing and sorry for not caring about it so far. If the MX is the exception, maybe the best is to just remove the filtering completely.
The SystemTime2 I would ignore for now. Can you open a new ticket if you think it is important?
can you give it a try?
Had some issues installing from marketplace...
I have now installed the updated binding and it seems like the previously ignored things now are installed and working correctly.
Thanks a lot for the excellent work!!
Thanks for the feedback. How did you install it finally and what where the problems with the marketplace?
I upgraded my system and afterwards the entries from Marketplace was not showing in Bindings (Paper UI).
The problem was solved by following these instructions:
https://community.openhab.org/t/solved-failed-downloading-marketplace-entries-received-fatal-alert-handshake-failure/52045/61