Dear community members, please do no use this thread for anything you see happen in 3.1M4 or any 3.1M.
It is to discuss issues that have been identified already to be caused by and specific to 3.1M4.
If you continue posting any sort of issue like you currently do, we quickly loose readability and noone’s gone neither read nor be able to help you with your issues any more soon.
So please: open your own threads in the first place. Thank you.
3 Likes
@Kai This is quite interesting, since the Metrics service broke the REST API with the switch from M3 to M4 also and I basically took over the whole way of creating a new REST endpoint from the Hue Emulation binding.
I’m seeing unexpected behaviour with M4 and the Hue Emulation.
After startup I cannot access the Hue Emulation status page at /api/status. It looks like the openHAB rest API is using /api and /rest.
If I stop and start the Hue Emulation it then takes over using /api which then seems to break the rest api
It seems, that in M4 were changed some OSGI and Jetty-Components which have negative effects for some bindings and other functions. So i think, this should be discussed here. if this is not the right place, it would be nice, if you tell us where is the right place.
Thank You
open an Issue on GitHub for the addon impacted.
@Dragonfly @Mercator1990 @pravussum @MikeJMajor
Issue is fixed
see [hueemulation] kills rest api and basic ui on M4 and SNAPSHOT · Issue #10656 · openhab/openhab-addons · GitHub
1 Like
This is not a binding problem. the problem is caused by an not correct/changed behaviour of the jetty-websocket libraries in M4. we can not fix it in the binding…but we dont find somebody who can help us…so at this time, the in openhab included binding of innogy-smarthome is useless…
i have opened an issue [InnogySmartHome] Bridge-Thing is not going ONLINE on OpenHAB 3.1.M4 · Issue #10650 · openhab/openhab-addons (github.com)
but nobody can fix it…
we have contacted LIVISI and the deverlopers reported us, that the websocket-request coming from OH is missing some protocol and header standards…the websocket is handled by jetty and jetty is openhab core…
so what we can do?
Ralph
Did you also try the latest snapshot (build 2391 or newer)?
openHAB now uses Karaf 4.3.2 with Jetty 9.4.40.v20210413 which maybe helps.
Yes…i tried the Snapshot from yesterday…Same error
Doesn’t sound like build 2391 which was only build today. Unless you are in Australia. 
ok…i tried it now again with Build 2391…same error
1 Like
Hi,
I tested 3.1 Milestone 4 yesterday for a very short time before heard that Milestone 5 will be today and hence I jumped today directly from M3 to Milestone 5.
I recognized that with M4 as well as with M5 the colored output in the karaf log has gone (INFO=cyan, ERROR=red, DEBUG=black, WARNING=magenta). Any idea how to get this back?
Between M3 & M4 there was an update to OSGi &, I believe, karaf. Perhaps that explains the change.
Thanks Bruce for this quick response!!! Ok, so the reason seems to be clear 
… The question is where and how to ask if this can be turned back 
If karaf was updated perhaps an apache karaf forum may have the answer.
Good question. I have found https://issues.apache.org/jira/browse/KARAF-7029, which seems to hint that the userdata/etc/org.apache.karaf.log.cfg file needs to be changed for the Karaf 4.2 to 4.3 upgrade.
The Karaf distro now contains:
color.fatal = "bright red"
color.error = "bright red"
color.warn = "bright yellow"
color.info = "bright green"
color.debug = "cyan"
color.trace = "cyan"
pattern = "\u001b[90m%d{HH:mm:ss.SSS}\u001b[0m %h{%p}{FATAL=${color.fatal}, ERROR=${color.error}, WARN=${color.warn}, INFO=${color.info}, DEBUG=${color.debug}, TRACE=${color.trace}} \u001b[90m[%t]\u001b[0m %m%n"
I couldn’t figure out, how to update our version of the file so that it keeps the same formatting, but re-adds the colors… Maybe you are more lucky and can come up with the correct update? (fyi @wborn)
1 Like
Hi @Kai,
taking these settings 1:1 seems not to work very well:
But it is a good hint where to start redefining the settings to get the previous output format 
EDIT I found this in Kais Link:
The problem comes from the org.apache.karaf.log.cfg. Our distribution still had the same configuration we used in 4.2:
pattern = %d{HH:mm:ss.SSS} | %-5.5p | %-16.16t | %-32.32c | %20.20X{bundle.name}:%X{bundle.version} | %m%n
Reverting this to what's shipped with 4.3.0 shows colors again.
Question is … “What is the default shipped with 4.3?”
This also did not bring the colors back 
It also seems that the log:DiSPLAY has now the “tail” option per default as I only get the last few lines when running the command???
I found this in the same thread that you have mentioned above:
> The karaf console => log:tail is no longer colored, but all white. I checked
> my org.apache.karaf.log.cfg file and there is no '--no-color' property there.
> So i debugged a bit
> org.apache.karaf.log.core.internal.LogEventFormatterImpl.getColor(PaxLoggingEvent,
> boolean) and found an issue there.
> return level2Color.get(event.getLevel());
> the map key is of type org.osgi.service.log.LogLevel, while event.getLevel()
> is of type org.ops4j.pax.logging.spi.PaxLevel (incompatible). So for testing
> purposes i changed to return level2Color.get(event.getLevel().toLevel());
> (which is the proper LogLevel type)
> and the console was colored again.
> I file this as minor although for me it is at least normal, i got very used
> to the color-coded log levels... :)
especially this part:
> ... So for testing
> purposes i changed to return level2Color.get(event.getLevel().toLevel());
> (which is the proper LogLevel type)
> and the console was colored again.
Does it make sense to fix this manually as a workaround until it is fixed in karaf?
I don’t where level2Color.get() is located Every hint is appreciated.