Closed GoogleCodeExporter closed 8 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
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
[deleted comment]
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
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
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
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
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
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
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
unassigned to make current state more transparent
Original comment by teichsta
on 21 May 2013 at 9:17
Original comment by kai.openhab
on 22 May 2013 at 8:14
@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
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
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
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
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
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
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
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:
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:
Thanks! Could you please provide the rule as well?
Original comment by teichsta
on 16 Jul 2013 at 8:19
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
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
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:
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
hlw31...@gmail.com
on 17 Oct 2012 at 11:01