noushadali / openhab

Automatically exported from code.google.com/p/openhab
GNU General Public License v3.0
0 stars 0 forks source link

Strip down to requirement #138

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
1. Feature Description
OpenHAB should be made to allow customisation of features to adress hardware 
bottlenecks. E.g., on the Raspberry PI/256MB RAM is valuable and an additional 
swap file stresses both, CPU and SD card.

Maybe ON/OFF like settings for these features could help:
- Jetty SSL
- GCal integration
- XMPP

So to make it briefly, maybe disabling internal 'bundles' would be great ;) 

2. Example Use Case
Embedded hardware platforms with resource restrictions, speed up on powerful 
machines, better choice of features

3. Some notices
I found many 'plugins' inside openhab/server/plugins. Is it possible to move 
them in order to disable them (f.e. org.openhab.io.gcal_1.0.0.201208172206.jar, 
org.openhab.ui.webapp_1.0.0.201208172206.jar)?

Original issue reported on code.google.com by hlw31...@gmail.com on 17 Oct 2012 at 11:01

GoogleCodeExporter commented 9 years ago
Update on this:

I managed to run eibd & openhab including persistence (db4o & rrd4j) and some 
additional bindings (f.e. KNX, exec, fritzbox, nh) on the raspberry pi r1 256MB 
& r2 512MB with a load far below 1 (1-min avg) and zero writes to sd card when 
running, thus extending the sd card's life.

I'd like to upload the needed files somewhere but I'm unsure where to do this.
Is it permitted to upload a pile of files to this issue or shall I update the 
wiki page with a tutorial?

Thanks

Original comment by hlw31...@gmail.com on 4 Nov 2012 at 11:27

GoogleCodeExporter commented 9 years ago
Sounds great :-)
What kind of files are these? You could also make them available to me and I 
could put them up in the download section - you could then reference them there 
from the wiki page.

Original comment by kai.openhab on 5 Nov 2012 at 8:26

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Thanks for your offer.

I've decided to create a own project on running openhab on the RPi and did so. 
Please see https://github.com/cribskip/OpenHABpi.

I'll describe my setup inside this project and link it to the hardware FAQ when 
ready.
All in all, the RPi seems to be the perfect platform for openhab *thumbsup*

KR

Original comment by hlw31...@gmail.com on 6 Nov 2012 at 2:22

GoogleCodeExporter commented 9 years ago
Ok, sounds like a good solution as well.
Nice to hear that it is running well on the RaspberryPi as I have one still 
waiting in my drawer to be installed. Did I get you right that you will also 
upload an SD card image with a complete installation?

Original comment by kai.openhab on 6 Nov 2012 at 8:47

GoogleCodeExporter commented 9 years ago
I'm undecided if I create a package for seperate installation or if I provide 
regulary SD card images. What do you think on this?

Original comment by hlw31...@gmail.com on 6 Nov 2012 at 9:40

GoogleCodeExporter commented 9 years ago
Both might be useful. But to get people having a quick success, I would vote 
for the SD card image!
We could then think of scripts to update installations, so that you would not 
have to update the image too often.
And you should tell me about any change that makes sense to include into the 
"standard" openHAB, of course!

Original comment by kai.openhab on 6 Nov 2012 at 9:55

GoogleCodeExporter commented 9 years ago
Thank you, hlw31. This project seems to be the missing node in running openHAB 
on RasPi. I have 3 of those on my desk, but never made openHAB really work on 
RasPi longer than a day without a crash. I'm in Sweeden now, but when I get 
back, you will receive a detailed feedback! :)

Regarding your question - both providing SD image and a separate package, would 
be great.
Thank you one more time for sharing your great work!

Original comment by mishoboss on 8 Nov 2012 at 4:51

GoogleCodeExporter commented 9 years ago
And one more thing that may be useful - I wrote a simple .sh file that is run 
when openHAB is fully loaded on the Pi. I run it using rule and EXEC binding. 
In that .sh there is a command that powers ON a GPIO pin on the Pi. On that 
that pin is a LED, so whenever openHAB is running, the LED is ON.

It might be useful to tweak this to check continiously if openHAB is running 
and if not for some reason, power off the GPIO. So you always have visual info. 
:)

Original comment by mishoboss on 8 Nov 2012 at 4:59

GoogleCodeExporter commented 9 years ago
So I created an image of my SD card but I am undecided if I may redistribute 
Oracle's Java with my image. Does anyone know about this?

Original comment by hlw31...@gmail.com on 9 Nov 2012 at 7:45

GoogleCodeExporter commented 9 years ago
unassigned to make current state more transparent

Original comment by teichsta on 21 May 2013 at 9:17

GoogleCodeExporter commented 9 years ago

Original comment by kai.openhab on 22 May 2013 at 8:14

GoogleCodeExporter commented 9 years ago
@hlw31 - I'm not sure if you can redistribute Oracle Java, but quick answer is 
probably not.  There are also some things you should generalize when you 
distribute an SD card image like regenerating the SSH keys for example, 
changing unique system identifiers.  I have seen other distributions for the 
RPi which simply have a "first boot" script which initializes everything and 
walks the user through some configuration scripts (ie; hostname & root password 
& generate new SSH keys & expand root fs to SD card size).  You can probably 
find some help out there for distributing.

Original comment by gee...@gmail.com on 4 Jun 2013 at 6:40

GoogleCodeExporter commented 9 years ago
As the start on the Rpi is taking rather long, it is strongly advised to change 
the scan interval in openhab.cfg to at least 45 seconds. Also ramping items, 
rules, sitemap, persistence like 30,45,60,75 improves startup-behavior.

I'm working on an install-script right now.

Original comment by hlw31...@gmail.com on 7 Jul 2013 at 12:46

GoogleCodeExporter commented 9 years ago
So, i just pushed some script to https://code.google.com/p/openhabpi/

Maybe it is advisable to close this issue then and discuss raspberry-specific 
issues there. 

Original comment by hlw31...@gmail.com on 7 Jul 2013 at 1:47

GoogleCodeExporter commented 9 years ago
Thanks a lot for your great setup script, that facilitates the RaspPi setup a 
lot!
Still, I would like to keep this issue open as I planned to do many more 
optimizations, like reduction of the number of bundles, performance 
optimizations, etc.

Original comment by kai.openhab on 8 Jul 2013 at 7:25

GoogleCodeExporter commented 9 years ago
Hi
I have just started using OpenHAB a couple of month a go and what great stuff. 
Thanks everybody.
It is working very well I have only had to restart it ones in 2 months. Don't 
know why that happened.
I am using it on a Beagle Bone Black and can relate to this article because of 
two things:
1. I have to start it up in two steps to make it start. first I start the 
OpenHAB up but with out the .item and .rules files. When OpenHAB is started i 
copy in the files manually. If I don't do this it won't start.
2. I use only the IHC and the Sonos bundle and when I press a button on my IHC 
it takes 6-7 sek. for the Sonos to react.
I have tried my setup on a mac air where it works perfectly and I have tried it 
on a Asus eeepc where it has the same performance as the BBB.
I will try to use some of the tricks and tips from the RPi page but I guess 
that the reaction speed will not be affected by this :-)

Anybody got any good advise to make the reaction time go down - other than 
bying new hardware :-)

Thanks for some great software.'

Regards Jesper

Original comment by for...@gmail.com on 15 Jul 2013 at 6:51

GoogleCodeExporter commented 9 years ago
Thanks a lot for your feedback Jesper!
Your first issue should be solvable by setting the folder refresh values to a 
higher value.
The response times are indeed inacceptable. I guess I will have to do some 
profiling on this to find the underlying problem. I do not see any reason why 
it should behave so slowly even on a small hardware.

Original comment by kai.openhab on 15 Jul 2013 at 7:04

GoogleCodeExporter commented 9 years ago
Jesper, could you please start in debug mode (use start_debug.xxx) and provide 
a "clean" openhab.log here?

Original comment by teichsta on 15 Jul 2013 at 7:14

GoogleCodeExporter commented 9 years ago
Hi again

I just tried to set higher values in the refresh rate in the config file. That 
did not change anything regarding start up it hangs when processing the project 
file:

Original comment by for...@gmail.com on 16 Jul 2013 at 7:12

Attachments:

GoogleCodeExporter commented 9 years ago
Hi Again

I have now tried to start it the old fashioned way by coping the rules and item 
files out before start and in after start up. that can be seen from the 
attached file.
When everything has been started up as you also can see from the file I press 
the IHC button and after 7 sec. it reacts on the Sonos:
1 new notifications received from controller
Executing rule 'Sonos play on ihc button'
7 sec pause
Controller state text.ctrl.state.ready

I does this a couple of times just to check :-)

Thanks for any input on this - it puzzles me bit that not even the refresh rate 
seem to make any difference. Hopefully one of you brilliant guys can see 
something that I do wrong. If you need any more input from me please don't 
hesitate to say so I am very eager to help.

Thanks in advance
Jesper

Original comment by for...@gmail.com on 16 Jul 2013 at 8:06

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks! Could you please provide the rule as well?

Original comment by teichsta on 16 Jul 2013 at 8:19

GoogleCodeExporter commented 9 years ago
Jesper, what I can see from the log is that you rule is executed pretty much 
immediately when notification is received from the ihc controller.

21:48:34.026 DEBUG o.o.b.ihc.internal.IhcBinding[:526]- 1 new notifications 
received from controller
21:48:34.113 DEBUG o.o.m.r.i.engine.RuleEngine[:305]- Executing rule 'Sonos 
play on ihc button'

21:48:55.483 DEBUG o.o.b.ihc.internal.IhcBinding[:526]- 1 new notifications 
received from controller
21:48:55.698 DEBUG o.o.m.r.i.engine.RuleEngine[:305]- Executing rule 'Sonos 
pause on ihc button'

21:49:23.836 DEBUG o.o.b.ihc.internal.IhcBinding[:526]- 1 new notifications 
received from controller
21:49:23.906 DEBUG o.o.m.r.i.engine.RuleEngine[:305]- Executing rule 'Sonos 
play on ihc button'

Obviously I cannot know when you have really pressed the button. So is 7 sec 
delay between button press and when ihc binding receive the notification or is 
the delay between rule execution and before sonos device reacts?

Original comment by pauli.an...@gmail.com on 16 Jul 2013 at 9:28

GoogleCodeExporter commented 9 years ago
Hi

I will add the rule when I get home.
Regarding the timing then:
I press the button on my IHC just miliseconds before the:

1 new notifications received from controller
then comes this output after a few milisec.:
Executing rule 'Sonos play on ihc button'
Then there is a 7 sec wait until the Sonos reacts and the output is:
Controller state text.ctrl.state.ready

here is a snippet from the file where the time shows the timegap:

BUTTON PRESS
20:49:53.588 DEBUG o.o.b.ihc.internal.IhcBinding[:526]- 1 new notifications 
received from controller
20:49:53.600 DEBUG o.o.b.ihc.internal.IhcBinding[:521]- Wait new notifications 
from controller
20:49:53.739 DEBUG o.o.m.r.i.engine.RuleEngine[:305]- Executing rule 'Sonos 
play on ihc button'
.
.
.
SONOS REACTS
20:50:01.779 DEBUG o.o.b.ihc.internal.IhcBinding[:1050]- Controller state 
text.ctrl.state.ready

Hope this cladifies a bit
Please say if you need more input

Regards Jesper

Original comment by for...@gmail.com on 17 Jul 2013 at 9:42

GoogleCodeExporter commented 9 years ago
Hi again

I promised to add the rules file.
So here it comes

Original comment by for...@gmail.com on 17 Jul 2013 at 2:59

Attachments:

GoogleCodeExporter commented 9 years ago
Hi All

I must be doing something wrong because not even if I raise the refresh values 
to 160 it makes any difference.

Any body got any ideas?

Thanks in advance.

Regards Jesper

Original comment by for...@gmail.com on 17 Jul 2013 at 3:35

GoogleCodeExporter commented 9 years ago
Controller state text.ctrl.state.ready is not related to button press. It's 
information from IHC controller state listener thread (controller state 
notification service need to be renewed every ~10 seconds).

I don't see any runtime.busevent notifications on your log?

e.g.
09:52:37.522 INFO  runtime.busevents[:46] - Kitc_Play state updated to ON
or
09:52:37.522 INFO  runtime.busevents[:46] - IHC_Kitc_Bryg_UR state updated to ON

Anyway, on your rule file you have  defined 

"when Item IHC_Kitc_Bryg_UR received update ON"
and
"when Item IHC_Kitc_Bryg_UR received update OFF"

which seems to be faulty, because when you push button, IHC controller will 
send both ON (button down) and OFF (button released) notifications. So both 
"Sonos play on ihc button" and "Sonos pause on ihc button" will be executed.

Original comment by pauli.an...@gmail.com on 19 Jul 2013 at 7:11

GoogleCodeExporter commented 9 years ago
Well, rules are correct if you have button which stay ON or OFF state.

This is now little bit off topic discussion, so maybe we should continue on the 
openhab discussion group. 

Original comment by pauli.an...@gmail.com on 19 Jul 2013 at 7:23

GoogleCodeExporter commented 9 years ago
Hi

I think the rule is ok as it is a on and off button that stay in state - in the 
IHC software.

Here is a print out of the CMD prompt of the OpenHAB to match the above input 
to give a little data from it:

First is a printout where I press the button in the OpenHAB GUI:

Button is pressed in web GUI 1 sec before it reacts then:
08:55:14.110 INFO  runtime.busevents[:42] - IHC_Kitc_Bryg_UR received command ON
08:55:14.173 INFO  runtime.busevents[:46] - IHC_Kitc_Bryg_UR state updated to ON
08:55:14.573 WARN  o.o.c.t.i.s.MapTransformationService[:90] - Could not find a 
mapping for '-' in the file 'en.map'.
08:55:19.575 INFO  runtime.busevents[:46] - Kitc_Play state updated to ON
08:55:19.598 INFO  runtime.busevents[:42] - Kitc_Play received command ON

As you can see from here it also takes 5 sec. to react.

Here is when I press the button on my IHC:
08:43:02.045 INFO  runtime.busevents[:46] - IHC_Kitc_Bryg_UR state updated to 
OFF
08:43:02.371 WARN  o.o.c.t.i.s.MapTransformationService[:90] - Could not find a 
mapping for '-' in the file 'en.map'.
08:43:07.297 INFO  runtime.busevents[:46] - Kitc_Play state updated to OFF
08:43:07.322 INFO  runtime.busevents[:42] - Kitc_Play received command OFF

In both cases i can't find this '-' thing can it be what takes the time?

Thanks in advance for you help.

Best regards Jesper

Original comment by for...@gmail.com on 28 Jul 2013 at 9:10

GoogleCodeExporter commented 9 years ago
Hey there,

I stumbled over this issue via a twitter-posting of @wunschik, who has 
significant delays using the hue-binding on a RasPi. He was sent to this thread 
and was asked to provide additional info, but seemingly didn't do so.

I don't know whether this is still of interest, but as I have a similar effect, 
I'd like to provide some additional info from my case here:

- OpenHab 1.2
- hard-float Raspbian with current Oracle Java
- besides the Hue-binding, I also use the DMX-binding with local OLA - the 
DMX-path works fine :-)

Whenever I switch a Hue bulb in openhab, top reports >95% for java for about 7 
secs or so, then it goes back to approx 3.3%. Mem-load stays at approx 20%. The 
Hue bulb is switched after a comparable delay of approx 7secs.

I then started openhab with a modified start_debug.sh, where I deleted only the 
"-Djava.compiler=NONE" option (so I ran debug mode *with* compiling). After 
startup was complete, I used the Hue switch and later a group switch and got 
the followig debug information. As you see, there is always a 7sec-delay 
between the binding receiving the command and actually having sent it. 
Furthermore, these add up to 21 secs when 3 bulbs are to be switched with a 
group switch. (I replaced hue-ip and secret here):

21:07:21.251 INFO  runtime.busevents[:42] - hue1_on_off received command ON
21:07:21.261 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'hue1_on_off'
21:07:28.658 DEBUG o.o.b.h.i.hardware.HueBulb[:256] - Sent message: 
'{"bri":255,"on":true}' to http://<hue-ip>/api/<secret>/lights/1/state

...

21:07:52.359 INFO  runtime.busevents[:42] - paperlamp_on_off received command 
OFF
21:07:52.529 INFO  runtime.busevents[:42] - doorlamp_on_off received command OFF
21:07:52.581 INFO  runtime.busevents[:42] - hue1_on_off received command OFF
21:07:52.591 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'OFF' for item 'hue1_on_off'
21:08:01.070 DEBUG o.o.b.h.i.hardware.HueBulb[:256] - Sent message: 
'{"on":false}' to http://<hue-ip>/api/<secret>/lights/1/state
21:08:01.323 INFO  runtime.busevents[:42] - hue2_on_off received command OFF
21:08:01.341 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'OFF' for item 'hue2_on_off'
21:08:09.129 DEBUG o.o.b.h.i.hardware.HueBulb[:256] - Sent message: 
'{"on":false}' to http://<hue-ip>/api/<secret>/lights/2/state
21:08:09.213 INFO  runtime.busevents[:42] - hue3_on_off received command OFF
21:08:09.222 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'OFF' for item 'hue3_on_off'
21:08:16.736 DEBUG o.o.b.h.i.hardware.HueBulb[:256] - Sent message: 
'{"on":false}' to http://<hue-ip>/api/<secret>/lights/3/state
21:08:16.817 INFO  runtime.busevents[:42] - gsAllLights received command OFF

Any ideas? Does it probably take so long to "construct" Hue-messages on the 
RasPi? Can I assist with any further information?

Original comment by frank.pa...@mobiles-arbeiten.de on 22 Aug 2013 at 7:32

GoogleCodeExporter commented 9 years ago
Thanks for the info, I have linked to it also in issue 377.

Original comment by kai.openhab on 23 Aug 2013 at 8:05

GoogleCodeExporter commented 9 years ago
Update / additional info: In order to isolate the latency issue a little 
further, I just wrote a small .py script based on the phue-lib from 
https://github.com/studioimaginaire/phue which does 128 iterations of making 
three set-requests per iteration. It takes 31.97 secs for 128 iterations, that 
is approx 0.25 secs per iteration or approx .08 secs per set-request.

Compared to the 7 secs experienced per command on the openhab-path, this would 
be a quite impressive overhead. Fascinating...

(linked in issue 377, too)

Original comment by frank.pa...@mobiles-arbeiten.de on 25 Aug 2013 at 8:03

GoogleCodeExporter commented 9 years ago
I am closing this issue as it is contains quite divers topics.
The main topic, why this issue has been opened, is to reduce the minimal 
footprint of openHAB. This will be definitely addressed with the Eclipse 
SmartHome project as this will modularize the core set of bundles.

Original comment by kai.openhab on 6 Dec 2013 at 5:34