GSD issues - all devices died.

[mkbrown69]

Hi folks!

I have an issue with all my GSD devices are dying and re-spawning until they hit the 50 retries. Both (the Radio Thermostat and the ISY994i driver) die with the same result code.

Code: [Select]

1843:#### START SETTERS #############################################################
#######
1844:def initialize()
1845:super
1846:@returnParamArray=Array.new
1847:end
1848:####  END  SETTERS #############################################################
#######
1849:end
1851:Return code: 134
3       08/03/15 09:59:41       189 (spawning-device)   Device died... count=34
/50 dev=189

I'm running 12.04 with the latest updates.  I notice from the 12.04 Wiki page that the requirement for Ruby 1.9 was added recently. Both Ruby 1.8 and 1.9 are presently on the system.

I'm wondering if anyone else has experienced similar issues. My likely next steps are to look at either reverting the 1.9 installation back to 1.8, or removing all the 1.8 Ruby packages. 

Anyone know what result code 134 means?

Thanks!

/Mike

Update:  I reverted back to pluto-generic-serial-device_2.0.0.46.14081629241_i386.deb (as it was the only previous version I could find in my package caches), and removed Ruby 1.9, restarted DCERouter, and my GSD devices are back in business!

/Mike

[pointman87]

Hey, i have the same issue, could you by any chance attach that pluto-generic-serial-device_2.0.0.46.14081629241_i386.deb to this thread? As i just reinstalled i don't have it available.

BR Daniel

[_if_]

have problems with my devices as well. running a pretty useless system at the moment...

[mkbrown69]

The Forum software limits the attachment size, so I can't post the GSD package here.

Looking into other options.

HTH!

/Mike

[pointman87]

After a little googling it seems ruby1.9.1 is buggy, maybe it would be better to depend on ruby2.0?

[phenigma]

Ruby will not be reverted to 1.8 going forward.  1204 is using Ruby 1.9.1 and 1404 is using Ruby 2.0.

There have been many changes in the ruby language that are biting some people during the alpha transition.  These issues will need to be worked through.  The biggest issue is changes in ruby syntax from 1.8->1.9.1.

Again, the issue here is ruby syntax changes.  Device Templates will have to be updated and will not be backwards compatible unless people are very careful about the changes.

I have a RadioThermostat here.  I am having very few issues with it since updating the ruby code.  Please do an sqlcvs update to get the latest code for it.  It should be completely backwards compatible with ruby 1.8 as well.

J.

[Marie.O]

Remember that changes to the DT in sqlCVS will not overwrite code that has been locally modified.

[mkbrown69]

Ruby will not be reverted to 1.8 going forward.  1204 is using Ruby 1.9.1 and 1404 is using Ruby 2.0.

There have been many changes in the ruby language that are biting some people during the alpha transition.  These issues will need to be worked through.  The biggest issue is changes in ruby syntax from 1.8->1.9.1.

Again, the issue here is ruby syntax changes.  Device Templates will have to be updated and will not be backwards compatible unless people are very careful about the changes.

I have a RadioThermostat here.  I am having very few issues with it since updating the ruby code.  Please do an sqlcvs update to get the latest code for it.  It should be completely backwards compatible with ruby 1.8 as well.

J.

Phenigma,

A few questions if you don't mind...

Which Radio Thermostat template are you using; The 3M50 or the CT-30/CT-80 one?  Which model thermostat do you have?  I'm running a CT-80 myself...

It also sounds like you've seen some common changes that have to be done to the templates. Could you point out what you've seen, so I have an idea as to where to start if I have to debug the ISY template?

Thanks to you and posde for your guidance on this!

/Mike

[phenigma]

First an overall response as I've seen things:

From what I can tell we have somewhere under 40 templates (total) that may be affected by the GSD updates.  Some of these templates are no longer used.  The vast majority of GSD templates are simple 'send only' templates that use the <$ > tags and will not require any updates/upgrades to function properly.   If your template parses return data from the device then you will likely need to make updates to the template (if someone else has not already done so).

A few questions if you don't mind...

I am happy to help! 

Which Radio Thermostat template are you using; The 3M50 or the CT-30/CT-80 one?  Which model thermostat do you have?  I'm running a CT-80 myself...

I use the CT30/CT80 template (DT2243).  I have a CT-80.  Mine is a rebranded version (in stickers/outer housing only) but an exact replica otherwise.  In Canada they are sold under the brand "Current Inovations".

It also sounds like you've seen some common changes that have to be done to the templates. Could you point out what you've seen, so I have an idea as to where to start if I have to debug the ISY template?

Mostly what I've seen is differences in handling nested commands lots of w.x.y.z() type stuff.  I find seperating those nested fn calls to seperate lines (even if you need extra variables) tends to solve some of the issues I've encountered.  Otherwise there have been some re-naming of library calls in ruby.

If you were to run 'screen -r CT30CT8097' you would see the screen session of the GSD device and the commands that are exectured on-the-fly as they are passed to the ruby interpreter.  This is how I've been monitoring things.  I think I've pushed all my changes there.

Any other errors that you have you can post here, or in IRC chat, and we'll try to help sort out your issues.



Thanks for your feedback!

Jason.

[mkbrown69]

Jason,

Thanks for the quick response!  I'm a Canuck as well, in Ottawa, so we have the same Tstat. You're in Kingston, right?

Nice to see you're using DT2243; I did some work on that one a ways back. Still have some ideas for it; they'll have to wait.  I'll re-sync up my local code with what's in SQLCVS and see what's changed, and go from there.

The ISY template has some major changes coming, so I may have to revert my local code to match SQLCVS, and then slowly roll forward with the new code. I have a Z-wave module coming soon for my ISY, so I hope to add support for that in the next batch of updates.

Is most of the development effort towards putting out a 12.04 release, or going past it to 14.04 instead?  Just wondering where to expend my effort...

Thanks for the assistance!

/Mike

[pointman87]

@Phenigma any hint on how to update the denon avr template to work with 1.9.1? Some commands are like <$"PWSTANDBY\r"$> and some are like OnDemand("PW","ON")

[Marie.O]

Probably the OnDemand function needs to be rectified. It checks for the current status before sending a change. So it probably has a read in there which can cause problems, iirc.

[phenigma]

mhm.  I'll have to turn off my CEC Adaptor and turn on the GSD control of my Panny  TV and the Denon AVR.  Posde's SWMBO would be devastated if the Denon stopped working.

Personally I hate that OnDemand fn, seems to obfuscate what is being done for no good reason.  Anyways.  Go into the screen session for the device and see if you can identify a specific error from the Ruby interpreter (this is how I've been checking/updating stuff here).

Since I have a denon avr I'll switch over and see what I can find out as well. 

J.

[Marie.O]

OnDemand has one very big reason: It limits the amount of switching happening on the Denon. Each time you send a change input, the HDMI output causes the display to re-calibrate. And there is no need to change what's already there.

That was the reason I implemented OnDemand.

[phenigma]

Ok.  Makes good sense to me.  Just never quite got the point nor have I userstood the german logging.

J.