Problem with HABdroid with latest nightly build of openHAB?

[Chris Jackson]

HABDroid has started crashing when I return to the main menu... If I open HABdroid, it shows the main menu fine, and if I click on an option, this is also ok, but when I return to the main menu it closes.

This just started today when I changed to the latest build of openHAB from Cloudbees. I also then upgraded to the latest HABDroid off cloudbees as well, but this doesn't help. I'm reasonably sure I'm running a stock standard build (ie no modifications from my side!).

Is anyone else seeing this problem? The other UIs still seem to work ok, so this seems to be a HABdroid problem, although given I didn't change HABdroid, I assume there's a change in what's being rendered from the REST interface? (although that's an assumption based on the fact that I only changed to the latest build of openHAB).

Cheers

Chris

[Victor Belov]

Hi,

HABDroid and openHAB have async development life cycles, so using both snapshot builds doesn't guarantee it works. It only works guaranteed if you use a release build of openHAB (1.3.x for now) and stock version of HABDroid from Google Play store :-)

Anyway, if you can collect log cat from this crash and send it to me this will fix the problem almost momentary. Stock build from Google Play uses crittercism to automatically report crashes to development team and we fix them asap, but snapshot has it disabled, cause the development version is meant to be used by developers :-)

Best regards,

Victor Belov

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.

[Chris Jackson]

Hi Victor,

Thanks - I'll try and grab the logs. I know that the REST interface has changed in the latest version - it's been split between a library and the original io.rest bundle, so I'm guessing something has changed in there. In any case, I fixing whatever causes this in HABdroid is probably good. 

 

I was going to take a look at this myself but have been working on some ZWave mods today.

 

On a separate note - is there a plan to move the source onto GitHub? I made some modifications a couple of weeks back to support colors to test out the sitemap changes that will hopefully be integrated at some stage and it would be good to be able to feed them into the main build when these are merged into OH.

 

Cheers

Chris

 

[Victor Belov]

Hi Chris,

Of cause that was meant! I just didn't test HABDroid against 1.4.0 cause I'm currently concentrated on closing of long trail of issues after being 2 months away from the project cause of moving into our new house :-) So log cat would be great to have.

Your improvements to item/sitemap rendering are super. I think it would be also great to think of a way of showing arrow stock-like indicators on numeric values, that would indicate if value went up or down in some last time period.

Anyway, as soon as I finish fixing this trail we will move HABDroid to github, I asked Thomas & Kai to give me some time on that. I think this will take about 2 weeks from now. After that I will be ready to accept pull requests and will be more then happy to help!

Best regards,

Victor Belov

--

[Chris Jackson]

Hi Victor,

Fully understand that you're not able to test out every version against every OH version - my original post was really a pointer that the new merge of the REST interfaces in OH may have a problem.

 

Anyway, moving to GitHub sounds great. I don't know if you've tried the sitemap changes, but HABdroid works really nicely with the dynamic visibility, and the colors of course make things nicer.

 

Thanks for a really nice app :)

 

I'll try and take a look at the crash issue later tonight or tomorrow.

 

Cheers

Chris

 

[Chris Jackson]

Hi Victor,

Attached is a log - please let me know if there's anything else you'd like me to try.

Cheers

Chris

[Victor Belov]

Hi,

This was quite easy to fix on the HABDroid side - just a stupid null pointer…

But there is really some problem with openHAB 1.4.0. I've just installed the last snapshot myself and there are some strange problems with connections reset… I'll investigate this later today to open an issue… Meanwhile pick up the latest HABDroid snapshot. You will not have the crashes, but unfortunately sometimes it will not work cause of problems on the REST API side…

Best regards,

Victor Belov

--

[Chris Jackson]

Hi Victor,

The following is the log.

I have an item in my sitemap which has no icon  (Text label="Lights" {...). It's a text item, but it has children. From memory, the sitemap icon defaults to the name of the widget (hence the text.png).

 

 

This hasn't changed recently though, so I still think something must have changed in OH REST output when I upgraded to the latest version yesterday.

 

I tried adding icons to the two widgets on the main menu that don't have icons (both text items as above), but that didn't help. I also loaded HABDroid and cleared the image cache, but that caused it to crash immediately as well.

 

 

Hmm - looking at the XML output in the debug below, there is no text.png specified, so that seems bit strange.

 

Anyway, please let me know if there's anything else you'd like and I can send it to you.

 

Cheers

Chris

 

 

 

 

 

W/System.err( 9751): at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)

 

W/System.err( 9751): at java.net.URLConnection$DefaultContentHandler.getContent(URLConnection.java:1018)

 

W/System.err( 9751): at java.net.URLConnection.getContent(URLConnection.java:199)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmapFromUrl(MyWebImage.java:147)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmap(MyWebImage.java:106)

 

W/System.err( 9751): at com.loopj.android.image.SmartImageTask.run(Unknown Source)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)

 

W/System.err( 9751): at java.lang.Thread.run(Thread.java:856)

 

W/System.err( 9751): java.io.FileNotFoundException: http://192.168.2.2:10080/images/text.png

 

W/System.err( 9751): at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)

 

W/System.err( 9751): at java.net.URLConnection$DefaultContentHandler.getContent(URLConnection.java:1018)

 

W/System.err( 9751): at java.net.URLConnection.getContent(URLConnection.java:199)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmapFromUrl(MyWebImage.java:147)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmap(MyWebImage.java:106)

 

W/System.err( 9751): at com.loopj.android.image.SmartImageTask.run(Unknown Source)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)

 

 

 

=======================================================

 

 

 

 

D/dalvikvm(20276): GC_CONCURRENT freed 433K, 9% free 12320K/13447K, paused 1ms+2ms, total 16ms

 

D/DocumentHttpResponseHandler( 9751): Got response = <?xml version="1.0" encoding="UTF-8" standalone="yes"?><sitemaps><sitemap><name>demo</name><link>http://192.168.2.2:10080/rest/sitemaps/demo</link><homepage><link>http://192.168.2.2:10080/rest/sitemaps/demo/demo</link><leaf>false</leaf></homepage></sitemap><sitemap><name>chris</name><link>http://192.168.2.2:10080/rest/sitemaps/chris</link><homepage><link>http://192.168.2.2:10080/rest/sitemaps/chris/chris</link><leaf>false</leaf></homepage></sitemap><sitemap><name>chris-x</name><link>http://192.168.2.2:10080/rest/sitemaps/chris-x</link><homepage><link>http://192.168.2.2:10080/rest/sitemaps/chris-x/chris</link><leaf>false</leaf></homepage></sitemap><sitemap><name>Test</name><link>http://192.168.2.2:10080/rest/sitemaps/Test</link><homepage><link>http://192.168.2.2:10080/rest/sitemaps/Test/Test</link><leaf>false</leaf></homepage></sitemap></sitemaps>

 

D/MainActivity( 9751): Response: org.apache.harmony.xml.dom.DocumentImpl@41d91230

 

D/MainActivity( 9751): Configured sitemap is on the list

 

I/MainActivity( 9751): Opening sitemap at http://192.168.2.2:10080/rest/sitemaps/chris/chris

 

D/OpenHABFragmentPagerAdapter( 9751): openPage(http://192.168.2.2:10080/rest/sitemaps/chris/chris)

 

D/OpenHABWidgetListFragment( 9751): withPage(http://192.168.2.2:10080/rest/sitemaps/chris/chris)

 

D/OpenHABFragmentPagerAdapter( 9751): getItem(0)

 

D/OpenHABWidgetListFragment( 9751): isVisibleToUser(FALSE)

 

D/OpenHABFragmentPagerAdapter( 9751): getPageWidth(0)

 

D/OpenHABWidgetListFragment( 9751): onAttach()

 

D/OpenHABWidgetListFragment( 9751): onCreate()

 

D/OpenHABWidgetListFragment( 9751): isVisibleToUser(TRUE)

 

I/OpenHABWidgetListFragment( 9751): onCreateView

 

D/AbsListView( 9751): Get MotionRecognitionManager

 

D/OpenHABWidgetListFragment( 9751): onActivityCreated()

 

D/OpenHABWidgetListFragment( 9751): onResume() http://192.168.2.2:10080/rest/sitemaps/chris/chris

 

I/OpenHABWidgetListFragment( 9751):  showPage for http://192.168.2.2:10080/rest/sitemaps/chris/chris longPolling = false

 

D/OpenHABWidgetListFragment( 9751): Start progress indicator

 

D/KeyguardViewMediator( 2275): setHidden false

 

D/KeyguardViewMediator( 2275): setHidden false

 

D/KeyguardViewMediator( 2275): setHidden false

 

I/SurfaceFlinger( 1939): id=10911 Removed iabdroid idx=3 MapSz=7

 

I/SurfaceFlinger( 1939): id=10911 Removed iabdroid idx=-2 MapSz=7

 

D/KeyguardViewMediator( 2275): setHidden false

 

D/DocumentHttpResponseHandler( 9751): Got response = <?xml version="1.0" encoding="UTF-8" standalone="yes"?><page><id>chris</id><title>Main Menu</title><link>http://192.168.2.2:10080/rest/sitemaps/chris/chris</link><leaf>false</leaf><widget><widgetId>chris_0</widgetId><type>Group</type><label>Heating</label><icon>heating</icon><linkedPage><id>00</id><title>Heating</title><icon>heating</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/00</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_1</widgetId><type>Text</type><label>Lights</label><icon>text</icon><linkedPage><id>01</id><title>Lights</title><icon>text</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/01</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_2</widgetId><type>Group</type><label>Climate</label><icon>temperature</icon><linkedPage><id>02</id><title>Climate</title><icon>temperature</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/02</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_3</widgetId><type>Text</type><label>Network</label><icon>network</icon><linkedPage><id>03</id><title>Network</title><icon>network</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/03</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_4</widgetId><type>Text</type><label>Sensors</label><icon>energy</icon><linkedPage><id>04</id><title>Sensors</title><icon>energy</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/04</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_5</widgetId><type>Text</type><label>Z-Wave Network</label><icon>fire</icon><linkedPage><id>05</id><title>Z-Wave Network</title><icon>fire</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/05</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_6</widgetId><type>Text</type><label>Weather [10.6 °C]</label><icon>sun_clouds</icon><item><type>NumberItem</type><name>Temperature_Outside</name><state>10.5625</state><link>http://192.168.2.2:10080/rest/items/Temperature_Outside</link></item><linkedPage><id>06</id><title>Weather [10.6 °C]</title><icon>sun_clouds</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/06</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_7</widgetId><type>Text</type><label>Energy Sensors</label><icon>energy</icon><linkedPage><id>07</id><title>Energy Sensors</title><icon>energy</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/07</link><leaf>false</leaf></linkedPage></widget><widget><widgetId>chris_8</widgetId><type>Text</type><label>Chart test</label><icon>text</icon><linkedPage><id>08</id><title>Chart test</title><icon>text</icon><link>http://192.168.2.2:10080/rest/sitemaps/chris/08</link><leaf>true</leaf></linkedPage></widget></page>

 

D/dalvikvm( 9751): GC_CONCURRENT freed 196K, 7% free 12552K/13383K, paused 12ms+13ms, total 47ms

 

D/OpenHABWidgetListFragment( 9751): Response: org.apache.harmony.xml.dom.DocumentImpl@41dfa178

 

D/OpenHABWidgetListFragment( 9751): Stop progress indicator

 

D/OpenHABWidgetAdapter( 9751): Stopping video for 0 widgets

 

D/OpenHABWidgetAdapter( 9751): Stopping image refresh for 0 widgets

 

I/OpenHABWidgetDataSource( 9751): Loading new data

 

D/OpenHABWidgetListFragment( 9751): processContent selectedItem = -1

 

I/OpenHABWidgetListFragment( 9751):  showPage for http://192.168.2.2:10080/rest/sitemaps/chris/chris longPolling = true

 

I/System.out( 9751): Not a DRM File, opening notmally

 

I/System.out( 9751): buffer returned 

 

I/MyWebImage( 9751): Cache for http://192.168.2.2:10080/images/text.png is empty, getting image

 

I/System.out( 9751): Not a DRM File, opening notmally

 

I/System.out( 9751): buffer returned 

 

I/System.out( 9751): Not a DRM File, opening notmally

 

I/System.out( 9751): buffer returned 

 

I/System.out( 9751): Not a DRM File, opening notmally

 

I/System.out( 9751): buffer returned 

 

I/System.out( 9751): Not a DRM File, opening notmally

 

I/System.out( 9751): buffer returned 

 

I/System.out( 9751): Not a DRM File, opening notmally

 

I/System.out( 9751): buffer returned 

 

D/lights  ( 2275): button : 2 +

 

D/lights  ( 2275): button : 2 -

 

I/SecHardwareInterface( 1811): setmDNIeUIMode (0)

 

D/dalvikvm( 9751): GC_CONCURRENT freed 335K, 7% free 12658K/13575K, paused 13ms+5ms, total 32ms

 

I/MyWebImage( 9751): Cache for http://192.168.2.2:10080/images/text.png is empty, getting image

 

E/SpannableStringBuilder( 9751): SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length

 

E/SpannableStringBuilder( 9751): SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length

 

D/i       ( 6078): scheduled task [GmmLocationControllerStatus Update]

 

W/System.err( 9751): java.io.FileNotFoundException: http://192.168.2.2:10080/images/text.png

 

W/System.err( 9751): at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)

 

W/System.err( 9751): at java.net.URLConnection$DefaultContentHandler.getContent(URLConnection.java:1018)

 

W/System.err( 9751): at java.net.URLConnection.getContent(URLConnection.java:199)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmapFromUrl(MyWebImage.java:147)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmap(MyWebImage.java:106)

 

W/System.err( 9751): at com.loopj.android.image.SmartImageTask.run(Unknown Source)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)

 

W/System.err( 9751): at java.lang.Thread.run(Thread.java:856)

 

W/System.err( 9751): java.io.FileNotFoundException: http://192.168.2.2:10080/images/text.png

 

W/System.err( 9751): at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)

 

W/System.err( 9751): at java.net.URLConnection$DefaultContentHandler.getContent(URLConnection.java:1018)

 

W/System.err( 9751): at java.net.URLConnection.getContent(URLConnection.java:199)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmapFromUrl(MyWebImage.java:147)

 

W/System.err( 9751): at org.openhab.habdroid.util.MyWebImage.getBitmap(MyWebImage.java:106)

 

W/System.err( 9751): at com.loopj.android.image.SmartImageTask.run(Unknown Source)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)

 

W/System.err( 9751): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)

 

W/System.err( 9751): at java.lang.Thread.run(Thread.java:856)

 

 

 

 

 

 

 

 

[Chris Jackson]

Thanks Victor,

I'll try and grab the snapshot this morning.

 

I thought there was probably an issue with the REST interface. I also noticed last night that it was actually crashing if I just left it on a single screen, so I guess this is all related to the connection reset issue.

 

Also, I assume  you know that the REST libraries changed in the past week?
 

Cheers

Chris

 

[Chris Jackson]

Hi Victor,

Please disregard the log that's just turned up - I actually sent this before the zipped version, but it never came through (until now!) so I resent a zipped log...

Strange!

Chris

[Victor Belov]

Hi,

There is really some change on the openHAB side. Long-polling requests are now served using Transfer-Encoding: chunked. But that's not really a problem, the problem is that in response openhab sends some junk with incorrect chunk header before going to wait until any changes happen to the requested site map page. Moreover, this junk is send prior to response even if I make an http 1.0 request, which switches off chunk encoding as it was introduced in http 1.1 spec. So I will open issue on that so that core guys would have a look at it. Meanwhile long-polling happens to broken, cause I don't think making a workaround on the client side is the right way of handling this…

Best regards,

Victor Belov

--

[Victor Belov]

Hi,

JFYI, I opened an issue for that:

https://code.google.com/p/openhab/issues/detail?id=506

Best regards,

Victor Belov

[Kai Kreuzer]

This pull request updated the REST API to atmosphere 2.0.0: https://github.com/openhab/openhab/pull/4

Tobias, Chris, you had this running for a while already, before I merged the pr, did you experience any problems with long-polling? Can you confirm that it is broken right now?

Regards,

Kai

[Chris Jackson]

Hi Kai,

I didn't run this until after the merge into the main repo, and as soon as I merged it I found the problem. Initially I assumed it was a problem with my changes to REST interfaces, so then tried the nightly build, and it was the same.

 

So, I'm reasonably sure that this change caused the problem, but unfortunately I didn't have it running before it was merged. It does however seem that other clients (eg GreenT) still work "ok" with the latest version, so it may not have been spotted.

 

Chris
 

[Victor Belov]

Hi,

I'm too careful :-))) Now the problem is that chunk of spaces which arrives prior to real response. It fails to be parsed as a document :-)

Best regards,

Victor Belov

[Tobias Bräutigam]

Hi,

I always tested the changed rest/rest-lib bundles together with my new cometvisu backend. As they were somehow conflicting, I thought the problems I had were caused by these conflicts. With my latest build those conflicts seem to be solved. And with the latest snapshot build of habdroid the crashes seem to be gone. The remaining problem is that, habdroid does not seem to react to item changes e.g. when I change an item in habdroid, the cometvisu shows the change, but if I change the item in cometvisu habdroid does not. I guess this happens because of the "chunk of spaces"-message Victor found.

@Victor
I would like to test if my cometvisu-backend also sends the spaces-message, but I don´t know how to reproduce that. Maybe you could explain in more detail how I can test that.

Regards,
Tobias

[Victor Belov]

Hi,

It's quite easy - just make a request with additional header X-Atmosphere-Transport with value long-polling

Best regards,

Victor Belov

[Tobias Bräutigam]

Hi,

thanks, got it. From my point of view, the sending of 8192 whitespaces is on purpose, please take a look here:
https://groups.google.com/forum/#!topic/atmosphere-framework/Ppv85ny2fuk

it is done by the PaddingAtmosphereInterceptor in order to tell the client browser wether it is connected or not in long-polling mode.
So this must by handled by the client and is no error on the server side, or am I getting it wrong?

Regards,
Tobias

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/Z-DVBXdNiYE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Victor Belov]

Hi,

Well. I don't think it is a good idea to send 8192 bytes of whitespaces. When using REST remotely on mobile connection, this will waste pretty much bandwidth. Moreover, this will lead to excessive charges, cause this will happen every time when long polling connection will restart. I don't see a reason to do that, cause it worked without it. So my proposal would be to eliminate it…

Best regards,

Victor Belov

[Tobias Bräutigam]

These whitespaces seem to be necessary for webkit based browsers and others, especially mobile ones. As all of openhab web-UI´s need webkit based browsers, I would recommend to not change the behaviour.

Just search for issues with padding in the atmosphere repository:
https://github.com/Atmosphere/atmosphere/search?q=padding&type=Issues

The setting jerseyServletParams.put("org.atmosphere.cpr.padding", "whitespace"), which is still available in the openhab source code in RESTApplication, suggests that this behaviour was intended even with the old version.
With the current version this setting is unneccessary, as is the default behaviour now.

The best way would be if the whitespace passig could be disabled from the client side, as it seems, that the browser based UI´s need it and HabDroid does not. But I don´t think that this is possible.
The only way to get rid of this is setting:
jerseyServletParams.put("org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults", "true");

in RESTApplications -> getJerseyServletParams() method. But this setting disables all Interceptiors and I guess some of them are quite usefull.

According to the sources Kai wrote the RESTApplication, maybe he can explain if the padding is needed or not.

Regards,
Tobias

[Victor Belov]

Hi,

Well, I see it from the following angle:

1. There were never any whitespace padding in long-polling requests before this moment, believe me, I work with openHAB REST API for ages :-)

2. It always worked without any problems in Chrome and Safari for ages :-)

3. This is excessive data transfer for mobile usage. Every polling request will generate extra 8K of data. Then imagine if you press 5 switches one by one on a page. This will mean 40K of data which nobody needs. This will introduce more latency in application response on slow mobile connections (yes, there are still places on the earth where openHAB users switch to EDGE and even GPRS :-)

So my proposal would be to eliminate this padding.

I think we need to ask Oliver Mazur who brought a lot of stuff into atmosphere in openHAB.

Best regards,

Victor Belov

[Chris Jackson]

I would tend to agree with Victor. I'd prefer to avoid 'large' amounts of unnecessary data - I travel abroad a lot and data charges aren't cheap. I never personally found any problem with it previously...

Can I suggest that this is made configurable in the openhab.cfg file. This way at least users will be able to decide for themselves if it is needed?

Chris

Sent from Samsung Mobile

[Tobias Bräutigam]

Hi,

I guess the old jerseyServletParams.put("org.atmosphere.cpr.padding", "whitespace") setting never worked, if
I understand your points (btw. I live in a place where only EDGE is available). For some stupid reason I always thought that the added whitespaces would by only 8Bytes long end therefore the added data wouldn´t be that "expensive".
I took a deeper look in the AtmosphereInterceptor-Configuration and found a way to get rid if it. I did a short test in my testing environment and it seems to work fine. But before I create a pull request for it, I would like to ask you, Victor, to test it as well, as you are more experienced with the REST API.

Lets see if this solution creates new problems. In that case we can think about making it configurable in openhab.cfg like Chris suggested or find another solution.

Regards,
Tobias

[Victor Belov]

Hi,

Would love to help. Where can I clone your version from to test it?

Best regards,

Victor Belov

<org.openhab.io.rest-1.4.0-SNAPSHOT.jar>

[Tobias Bräutigam]

Hi,

I justed pushed it to the cometvisu branch of my clone:
https://github.com/peuter/openhab/tree/cometvisu

The change is quite simple:

-        jerseyServletParams.put("org.atmosphere.cpr.padding", "whitespace");

+        jerseyServletParams.put("org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults", "true");

+        // use the default interceptors without PaddingAtmosphereInterceptor

+        // see: https://groups.google.com/forum/#!topic/openhab/Z-DVBXdNiYE

+        jerseyServletParams.put("org.atmosphere.cpr.AtmosphereInterceptor", "org.atmosphere.interceptor.DefaultHeadersInterceptor,org.atmosphere.interceptor.AndroidAtmosphereInterceptor,org.atmosphere.interceptor.SSEAtmosphereInterceptor,org.atmosphere.interceptor.JSONPAtmosphereInterceptor,org.atmosphere.interceptor.JavaScriptProtocol,org.atmosphere.interceptor.OnDisconnectInterceptor");

in bundles/io/org.openhab.io.rest/src/main/java/org/openhab/io/rest/RESTApplication.java

Regards,
Tobias

[Victor Belov]

Hi,

Tobias, I can’t build this snapshot :-( Have you ever tried to do mvn build on it?

It fails somewhere in udp/tcp binding….

Best regards,

Victor Belov

[Tobias Bräutigam]

Hi Victor,

yes I did build it with mvn, just did an mvn clean install to test it again. It´s working.
I just commited some small changes, which shouldn´t make a difference, but at least the remote repository is now the same as my local one. I have no idea why it is not working, can you please give me more information about the error?

Regards,
Tobias

[Victor Belov]

Hi,

Ok, that was a tcp binding depending on java 1.7 problem…

Anyway, I’ve just built your git clone and tested it - it still sends those 8K of spaces in long-polling response :-(

Have you tested it yourself?

Best regards,

Victor Belov

[Tobias Bräutigam]

Hi Victor,

I tested that of course and I am using it in my production system already. When I query my openHAB server with
curl --header "X-Atmosphere-Transport: long-polling" -v http://localhost:8080/rest/sitemaps/main/0204

I get the answer:
* Adding handle: conn: 0x1d4caa0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x1d4caa0) send_pipe: 1, recv_pipe: 0
* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /rest/sitemaps/main/0204 HTTP/1.1
> User-Agent: curl/7.32.0
> Host: localhost:8080
> Accept: */*
> X-Atmosphere-Transport: long-polling
>

Without any whitespaces. Before the change I also had the whitespaces in the answer to the query above.
Could you please check the source of your checkout, if it looks like this in the lines 191-194 (thats what I changed):
https://github.com/peuter/openhab/blob/cometvisu/bundles/io/org.openhab.io.rest/src/main/java/org/openhab/io/rest/RESTApplication.java

Or maybe you are using another way to test. Perhaps you can describe how you tested it?

Regards,
Tobias

[Victor Belov]

Hi,

Ok, sorry, I went a wrong branch :-) building to test!

[Victor Belov]

Hi,

Tobias, it’s all back to normal now! So I would suggest to merge this into main !

Best regards,

Victor Belov

[Tobias Bräutigam]

Ok, pull request #603 created. Thanks for testing.

Regards,
Tobias

[Kai Kreuzer]

Cool, thanks Tobias!

Just merged it.