MisterHouse 3.0 Release #223
Conversation
…ttery Status The following likely only works for i2cs devices, I think all Remotelinc 2 devices are i2cs? It at least works on rev 1.4. - set_awake_time sets = sets the time in seconds that the remote will remain awake after sending a command. The default is 4, it can be set up to 254 seconds, with 255 being always awake. - get_extended_info = is primarily added to get the battery level. Battery level is returned as a byte, but the number does not immediately make sense. I will have to let the batter run down some to better understand what it means. At the moment, I have the code set to call get_extended_info whenever the all_link_report is received. This report represents the last message sent by the device before the awake time begins to run. In the future, an additional function can be added to only call get_extended_info if it hasn't been called in x hours. N.B. in order for set_awake_time to work properly, the engine version of the device must be known. #172
I think that the battery level is reported is volts * 50. Online it lists the battery voltage as 3.7 and I am getting numbers like 177 right now. Finally, one stray comment from Insteon suggested that they believe 0xA3 or 163 to be the low voltage warning level.
This is a generic object that is "tied" to the battery events in the parent RemoteLinc. It can be used to display the battery voltage on the RemoteLinc on the MH web page or to directly tie events to rather than using the low_battery_event code.
No need to reinvent the wheel, low batter events can be tracked using the child objects and tied events
If the device doesn't hear the first request, it won't be awake to hear subsequent ones. Sending subsequent messages only slows things down.
Uses Socket_Item instead of direct socket connection to avoid pauses in main loop. Stores device state in Generic_Item state variable now. PIO, Latches, and Sense now use state values of ON and OFF.
Insteon: 3000+ Lines of Documentation
Owfs update
Fix issue 210
Insteon: Timeout After Receipt of AllLink Broadcast to Avoid Collision w...
Enable Update_Docs to Scan Subdirectories; Stop Deleting Distro Files; Fix Docs CSS
Insteon IOLinc: Fix Relay Momentary Settings; Prevent Duplicate Sensor Messages
|
Hi Kevin, I'll make the new release tonight and I will document the process I follow on the wiki. Kind regards, Op 15-jun.-2013, om 04:05 heeft Kevin Robert Keegan notifications@github.com het volgende geschreven:
|
|
Kevin, I'm probably missing something: is it the intention that the changes in this pull request are merged into master before making the v3.0 release? The thing is that I can't merge your pull request automatically, so I don't know if it is your intention to merge these changes manually or if something went wrong with the pull request that you want to fix first. Lieven. |
|
I will be quite interested in what can be used as the ChangeLog file. (Need it for the debian packaging...) |
|
Hi RJ, the changelog is here: Kind regards, On Thu, Jun 20, 2013 at 3:29 AM, Robert James Clay <notifications@github.com
|
|
I've synced with Kevin on this pull request. I'll take care of the new release before the weekend and close this pull request when it is available. |
|
Done, the problem originated from a small conflict in the VERSION file and the related code that was updated in both branches. In the next updates to stable this should not happen anymore. I've documented the process for later reference here https://github.com/hollie/misterhouse/wiki/Contributing#branches-naming-convention-and-stable-releases |
|
Cool, thanks Lieven. Again, sorry I hadn't realized there was a conflict, Quick question about the stable release procedure. How should the VERSION
On Thu, Jun 20, 2013 at 12:42 PM, Lieven Hollevoet <notifications@github.com
|
|
Hey Kevin, absolutely no problem, detecting the conflict was as easy as running the commands I wrote in the wiki. Concerning the VERSION file: I'm in doubt. If we update it in the stable branch (as I did now, first merge master into stable and then update VERSION in stable) then I think we should not end up with a conflict. The only problem this time was that we had a conflict because VERSION and the related code in bin/mh were adapted in more than one branch. I think that if we don't change the VERSION file any more, the next merge of master into stable will go smoothly. Then we just update the VERSION file again in stable. An another note: I invite you to announce the new release on the list. You did most of the work according to me :-) Template: Hello list, I have just updated the stable branch of the MisterHouse git repo to v3.0. If you want to know what changed, the changelog is here: If you are running stable already then updating to this new version is as easy as running 'git pull'. A big thanks to all the contributors for keeping the awesome project alive!Kind regards, Op 20-jun.-2013, om 21:47 heeft Kevin Robert Keegan notifications@github.com het volgende geschreven:
|
|
Hello, On 06/20/2013 03:47 PM, Kevin Robert Keegan wrote:
Why would there be any conflicts? The code in stable should be unchanged Cheers, Eloy Paris.-
|
|
I was thinking something like the following example:
My git skills are pretty weak so I may be going about this wrong. |
|
On 06/20/2013 04:08 PM, Kevin Robert Keegan wrote:
I see. Yes, this definitely causes a conflict. I am still trying to
This way you are not updating VERSION in stable other than through a I got used to this before Git. I don't know if Git and its seamless and
They stronger than mine; I am still trying to finish reading the Git Cheers, Eloy Paris.- |
|
Hey guys, Op 20-jun.-2013, om 22:26 heeft Eloy Paris notifications@github.com het volgende geschreven:
Wait wait, first this note: according to me the reason we had a conflict now was because in both master and stable the same files were changed at the same lines. This should not happen anymore in next releases.
Yes, this is also a possible way to go.
Not necessarily. We can use this, but we can also use the way I did it now: master VERSION remains at 'unstable' and once we make a new stable branch we modify (in stable) the content of the file to v3.x.
Actually, I don't think your git skills are weak, considered the amount of contributions that flawlessly merged into master. Anyhow: I don't hold any decision power on what concept we use. My only 2 cents is that it is important to have the 'unstable' term in the master branch so that it is clear that new people starting out with MisterHouse are not running the development branch. Kind regards, |
|
On 06/20/2013 04:36 PM, Lieven Hollevoet wrote: [...]
Okay.
Okay.
Indeed. And he used branches and a lot of fancy Git things.
I think your approach is fine. Cheers, Eloy Paris.- |
Ahh, that is where I was confused. I was avoiding any direct commits to the stable branch. Yes, with that design there shouldn't be any conflicts. |
|
Hi Lieven! On Wed, 19 Jun 2013 23:59:52 -0700
That's useful for those who have a good Internet connection but not
I figure to use the file docs/updates.pod for it, patching it with at Since the pull has been closed, I'll follow up to the mailing list RJ Clay |
I think we are ready to push master into stable and release 3.0. The master branch seems to have been working fine for those who have been using it for the past week, at least I have not heard otherwise. Besides the documentation, today's pushes solved a few nits that shouldn't and haven't caused any issues for me. I also added extensive notes to https://github.com/hollie/misterhouse/wiki/Changelog.
So with that, we should be good. I confess I didn't pay attention to how the versioning is supposed to work. Should I be updating VERSION in the master branch? I assume that since it is set to unstable, it only gets changed in the stable branch.