-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial contribution of Astro binding. #113
Conversation
http://eclipse.org/smarthome/schemas/config-description-1.0.0.xsd"> | ||
|
||
<config-description uri="config:astro-config"> | ||
<parameter name="latitude" type="decimal" required="true"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest merging latitude and longitude into one string property (syntax "51.343,-140.32") with context "geolocation". This would allow UIs to use a map to directly pick a location. Having these both parameters separately makes it more complicated.
Thanks a lot for this binding Gerhard and sorry for coming back to you so late! I noticed that items do not receive a status update if they are newly created - as the refresh interval is usually pretty long, it would be nice to receive values immediately. I think this is probably not a problem of your binding, but should be rather triggered by the framework itself. Did you already think about this? In this context, I noticed that it is not possible to send a "REFRESH" command to the channels. Note that this did not exist in openHAB 1. It should trigger a status update for a certain item, so your binding should handle this, if possible. |
Hi Kai! I implemented/changed the things you mentioned. Currently i don't know when a item is newly created, there is no notification. So i can't immediately publish the value. BR, Gerhard |
Thanks Gerhard!
Yes, I agree. I think if the framework would simply send a REFRESH command to a channel for which a new item has been linked, that should probably do the trick. |
xsi:schemaLocation="http://eclipse.org/smarthome/schemas/config-description/v1.0.0 | ||
http://eclipse.org/smarthome/schemas/config-description-1.0.0.xsd"> | ||
|
||
<config-description uri="config:astro-config"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This uri needs to follow a certain naming convention in order to make sure that there are no clashes, see https://github.com/eclipse/smarthome/blob/master/docs/sources/architecture/configuration.md#xml-structure-for-configuration-descriptions. It probably should be thing-type://astro:config
.
Hi @gerrieg , after having upated the target platform with the improved lifecycle handling, I had another look at this PR and just have a few more comments. Once these are addressed, I'd be ready to merge this PR. |
Hi @kaikreuzer ! 1.) The mentioned jobScheduler is my own Quartz scheduler, not the scheduler in the BaseThingHandler. 2.) I implemented the EqualStateFilterHandler, because i don't want to flood the bus with unnecessary events. The user can specify a interval in the config. In this interval, all states are calculated and of course sent to the bus. My interval is 180sec, so every three minutes all items are updated, even if the state is the same. State updates may not be expensive, but what about Rules, Persistence etc. I agree, that this should be done by the framework, but currently it doesn't. So what should i do with this class? Will you implement this feature into the framework itself? 3.) If i change the uri to thing-type://astro:config, i get this exception:
Best, Gerhard |
1.) I did not comment the line with the jobScheduler, but the one with the statusUpdate. Btw, do you really need your own scheduler? I do not like having so many different thread pools in the system, I'd prefer to get the number of threads down. 2.) Please remove it. Sending update events is the suggested way.
They both allow reacting only on change events, so they filter by themselves already. 3.) Interesting - sounds as if the documentation is incorrect then. So maybe better have a try with |
1.) I am using the provided Quartz scheduler. It's required, because i need a cron trigger for the daily midnight job. With the ScheduledExecutorService from the BaseThingHandler i can only calculate a delay to midnight which is problematic with clock drifts and daylight savings. 2.) I'm not happy about removing the EqualStateFilterHandler, but you are the boss 😉 I still hope, that the framework provides this functionality someday. 3.) I have another issue now ... i wanted to start the positional job only if at least one item is linked to a positional channel. In the initialize() method of the ThingHandler, the items are not yet linked. So how can i do that? |
|
1.) I need to set the thing ON-/OFFLINE, based on valid-/invalid thing config. So what's the correct way to do that? 2.) Yes, fully agree! 3.) Thanks, implemented |
Where has the cancelling of the jobs now gone? This still needs to happen when a handler is disposed - or has this moved anywhere else now? I could not find it... |
It has been in the restartJobs(), but because of the delay it was to late to delete the jobs at shutdown, i fixed this now. Still have to learn how everything works exactly, so sorry for the circumstances. |
Well, we still have to document things in order for you to easily learn it :-) Thanks for your fixes, looks all good to me now. |
Signed-off-by: Gerhard Riegler <gerhard.riegler@gmail.com>
Definitely! Sometimes i don't know if it's my mistake, a bug in the framework, the feature is not implemented or i am using something wrong. I'm still rely on help from you and the other framework genius. So i would like to say thank you for your great support! Now i can continue with the Homematic binding and try find out how this works: https://bugs.eclipse.org/bugs/show_bug.cgi?id=461663 BR |
Awesome, thanks for your work! |
@gerrieg: May I ask you to create a short documentation for this binding until Sunday (May 24th)? |
Added a simple documentation with #246 |
Hi JP! Since a few weeks, the core framework supports trigger-channels. I can now implement the missing functionality into the Astro binding. Regards,
|
Hi Gerhard, thanks for the hint using OH1 version! Thanks for your efforts! Joerg Am 04.11.2016 um 14:46 schrieb Gerhard R.:
|
Signed-off-by: Gerhard Riegler gerhard.riegler@gmail.com