Astro Binding with strange notation

Hi everyone,

due to a system crash I had to reinstall OH2 from scratch today. I used the most recent Openhabian Image and configured everything just like I had it sat up before. One thing though was different this time: The ASTRO binding created interesting channel names. Instead of “astro:sun:local:civilDusk#event” as it was before, I now have “astro:sun:06cc0a26:civilDusk#event”. Can somebody please explain to me what happened?

Additionally, I cannot use Events in Rules anymore, as the Designer complains about "no viable alternative at input “Channe” and according to the logs, there is an error when parsing the shutters.rule
2017-08-23 20:26:42.709 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model ‘shutters.rules’

2017-08-23 20:26:42.717 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model ‘shutters.rules’ is either empty or cannot be parsed correctly!

2017-08-23 20:26:45.693 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘shutters.rules’

What’s going on here ?

Designer is significantly behind the rest of OH. The current working version of Designer 0.8 knows nothing about channel triggers. I assume the above “Channe” is a typo and you really have Channel in your file.

But just because Designer marks it wrong doesn’t mean it won’t work.

But the warning in the log is more meaningful. There is a major problem in your rules for that makes it not parsable. it could be a missing fully bracket or parents, a stay hidden character, etc. look for other errors in Designer.

Thanks for clarifying the designer thing. Interesting enough, that so many people strongly recomment to use it because of the syntax checking :slight_smile: (The missing “l” really only was a typo).

What made me nuts is, that the rules file was simply copied over from the old installation where it worked fine. So not sure why the same file, being unchanged, is no longer working.

In the meantime I have reinstalled the entire system again, as I had numerous errors being thrown during the setup of the other system. Strange.

So the new system seems to work now. The strange notation of the channels is gone and the (still unchanged) shutters rule is working again as well. Really strange.

It is the best we have. And most of us who do recommend it are sick of people posting horribly syntactically incorrect code that Designer would immediately tell them what is wrong. The only thing that Designer 0.8 cannot do is recognize Channel triggers and third party Actions. Every other aspect of Designer works just fine. So as long as you are aware of these two limitations it works really well for syntax checking.

Depending on the nature of the crash the file may have become slightly corrupted.

Are you using the same SD card? Strange behaviors like these often point to a failing SD card. Keep an eye on it and if you continue to see weird behaviors you should consider replacing the SD card.

Thanks again, this time for clarifying which components of designer are not up to speed.

I used the same SD card, which was anyway realtively new (about 4 month old).

So for the time being, the system is up and runnig again, no specific errors currently. I have moved NodeRed to a second RPi, just to make sure there are no problems caused by NR.

The age of an SD card does not always guarantee that it hasn’t worn out. Some people have reported SD cards going bad in a couple of weeks. I’m not saying your’s has, just that you should still keep an eye out for strange behavior. And because OH is a write heavy application, you should spend the time to come up with a good backup and restore procedure and consider running it off of an attached HDD or SDD rather than SD card.