Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mkbrown69

Pages: [1] 2 3 ... 14
Users / GSD issues - all devices died.
« on: Today at 04:06:35 am »
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()
1848:####  END  SETTERS #############################################################
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?



Update:  I reverted back to pluto-generic-serial-device_2. (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!


Installation issues / Re: NIC Issue (Working Solution)
« on: Today at 03:54:57 am »

I've seen the same thing on a number of occasions.  Looks like one of the networking "automagic" scripts is leaving a template stub behind after it's done it's business. Haven't had time to track it down and lodge a ticket/patch.

Just wanted to confirm that you aren't the only one who's seen it.



Installation issues / Re: LMCE-1404 20150308181930157 reboot loop
« on: March 28, 2015, 04:11:54 am »

14.04 is using Samba 4.1, vs the Samba 3 in 12.04. There was/is a bug in the Ubuntu issue tracker for nmbd starting before smbd, so that could be an issue.  There's also two new init scripts in /etc/init.d (samba and samba-ad-dc) which may play into this.  It could also be that the current LMCE managed smb.conf file is not compatible with Samba 4.1.

I haven't looked into this specifically, but I am starting to look at Samba AD support in 14.04 (playing with Zentyal 4 right now).

Just thought I'd point that out as a possibility.  HTH!


Developers / Re: Developing a Weather Plugin, videos
« on: December 23, 2014, 05:17:23 am »
Thanks Thom and Phenigma! 

Much appreciated!  I hope Thom's feeling better soon, so he can enjoy the holidays!

(Unfortunately, you have to get used to it;  when you have young kids, they pretty much get sick every winter for the first 6 years.  Been there, done that twice; now dealing with the "tween" stage  ;) )

Happy Holidays to the LMCE community!


Developers / Re: Developing a Weather Plugin, videos
« on: December 22, 2014, 04:10:19 am »

Looks like there's a missing graphic file that's causing the proxy orbitor to crash when selecting the radar button, if there isn't a radar graphic in the feed.  I would've filed it into Trac, but it doesn't seem to use the same credentials as the forum.

In the file here:

Line 54 references #define FILE_NO_RADAR_DATA "/usr/pluto/share/weather_no_radar_data.jpg"

That file is not present in the latest packages.  Everything else seems to be working fine though!

I've got current conditions going from the ISY driver to the weather plugin, and it's working well. Just working on getting all the forecast stuff parsing properly from the ISY subscription feed, and then that'll be straight forward to feed into your weather plugin.

Excellent work!  Thanks!


Developers / Re: Developing a Weather Plugin, videos
« on: December 15, 2014, 04:37:48 am »
Thanks for building the updated packages for the weather plugin!

I was starting to think that the plugin wouldn't work with RoamingOrb & proxy orbitor, or that I hadn't configured the plugin properly, as it wasn't working with the test harness.  With the new packages, it's now working, and I can see the results in RoamingOrb.

One thing I did notice in RoamingOrb, is that when I tap the radar image button (and there isn't a radar image to go to, tapping any button (like the home button) causes the proxy orbitor to die.  It's reproducible, and I did manage to get a clean log trace from restart through to crash.  This is the tail end, where it died.

Code: [Select]
05      12/14/14 22:12:01.655           Socket::ReceiveData 0x8dedd88 failed, b
ytes left 0 start: 660000 1: 0 1b: 0 2: 0 2b: 0 m_Socket: 5 Event Dev #38 <0xb76d2
05      12/14/14 22:12:01.655           Socket::ReceiveString2 ReceiveData fail
ed m_Socket: -1 Event Dev #38 <0xb76d2b40>
05      12/14/14 22:12:01.655           Socket::SendReceiveMessage didn't get v
alid response ReceiveData failed <0xb76d2b40>
05      12/14/14 22:12:01.655           InternalSendCommand cannot send with re
turn message.  type 1 id 84 to 423 Going to quit <0xb76d2b40>
05      12/14/14 22:12:01.658           Socket::ReceiveData 0x8de57e0 failed, b
ytes left 0 start: 600000 1: 0 1b: 0 2: 0 2b: 0 m_Socket: 6 Command_Impl1 Dev #38
05      12/14/14 22:12:01.659           Socket::ReceiveString2 ReceiveData fail
ed m_Socket: -1 Command_Impl1 Dev #38 <0xb5fffb40>
05      12/14/14 22:12:02.000           Socket::ReceiveData 0x8de8ff8 failed, b
ytes left 0 start: 660000 1: 0 1b: 0 2: 0 2b: 0 m_Socket: 4 Event Dev #38 <0xb57fe
05      12/14/14 22:12:02.000           Socket::ReceiveString2 ReceiveData fail
ed m_Socket: -1 Event Dev #38 <0xb57feb40>
01      12/14/14 22:12:02.000           Socket::PingFailed 0x8de8ff8 Event Dev
#38 (socket id in destructor: -1 0x8de57e0, ch: (nil)) <0xb57feb40>
01      12/14/14 22:12:02.001           Socket::PingFailed 0x8de57e0 Command_Im
pl1 Dev #38 (socket id in destructor: -1 (nil), ch: (nil)) <0xb57feb40>
05      12/14/14 22:12:04.246           TCPIP: Closing connection to -1 (Proxy_
Orbiter) 0xb60005e0 m_Socket: 10 <0xb3afcb40>
05      12/14/14 22:12:04.448           Dropping all sockets... <0xb76d4700>
05      12/14/14 22:12:04.459           Done dropping sockets! <0xb76d4700>
05      12/14/14 22:12:04.460           Socket::SendData socket is invalid <
05      12/14/14 22:12:04.460           Socket::SendMessage *failed to send* ty
pe 1 id 255 from 38 to 9 <0xb76d4700>
05      12/14/14 22:12:04.460           InternalSendCommand cannot send with re
turn message.  type 1 id 255 to 9 Going to quit <0xb76d4700>
05      12/14/14 22:12:04.460           Orbiter reloading... <0xb76d4700>
05      12/14/14 22:12:04.460           Orbiter quiting... <0xb76d4700>
05      12/14/14 22:12:04.460           Got an on quit.  Pushing an event into
SDL <0xb76d4700>
05      12/14/14 22:12:04.460           Got an on quit.  Pushing an event into
SDL <0xb76d4700>

Want me to file a Trac ticket?  I have a complete log trace from the proxy orbitor re-spawning to where it quits.  It might need a default "No Radar image" image file...

Now that Universal Devices has released the new firmware for the ISY-994i with HAM Weather support (replacing the previous Weatherbug support), I now plan on adding support for the LMCE weather plugin to my ISY GSD driver.  It'll go a lot smoother now that I know I didn't mess up anything with the weather plugin.



Users / Re: What do you think of this as Server?
« on: November 14, 2014, 04:46:34 am »
My core is virtualized (Debian KVM host).  The block device used as the OS drive is a LVM based logical volume presented from the host, and that volume group is sitting on an SSD (along with the OS volumes for some other virtual machines).

Performance is good, even with other VM's hitting the SSD.  SSD's excel at random I/O :)



Users / Re: apt-get upgrade problem
« on: October 21, 2014, 05:26:06 am »
Hi folks!

It's probably best if we know what you're dealing with.  You might want to take a peek at my post here for which version of bash you should be on for your given version of Ubuntu/LinuxMCE.

Specifically, run this:

Code: [Select]
sudo apt-get update && cat /etc/lsb-release && sudo apt-cache policy bash
Followed by this (which should show the diversion of sh to dash):

Code: [Select]
# dpkg-divert --list /bin/sh*
diversion of /bin/sh to /bin/sh.distrib by dash
# ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Mar 29  2012 /bin/sh -> dash

Probably the easiest way to patch bash and fix any potential diversion issues is to reinstall both shells.

Code: [Select]
#sudo apt-get install --reinstall bash dash

Let us know how that goes for you.



Users / Re: Shellshock vulnerability - do we need to do anything?
« on: October 03, 2014, 01:49:00 am »
You really want to patch your bash.  There are 6 CVE alerts against this, all with a CVSS score of 10 (meaning really bad).  I've been dealing with this at work, on almost every flavor of *nix out there.

Code: [Select]
sudo apt-get update && cat /etc/lsb-release && sudo apt-cache policy bash
If Candidate is not the same as Installed, you're not patched to the latest available.

Code: [Select]
  Installed: 4.2-2ubuntu2.5
  Candidate: 4.2-2ubuntu2.5
  Version table:
 *** 4.2-2ubuntu2.5 0

Your version number should be equal or greater than the ones listed at this link:

Ubuntu 10.04 LTS (Lucid Lynx):   released (4.1-2ubuntu3.4)
Ubuntu 12.04 LTS (Precise Pangolin):   released (4.2-2ubuntu2.5)
Ubuntu 14.04 LTS (Trusty Tahr):   released (4.3-7ubuntu1.4)
Ubuntu 14.10 (Utopic Unicorn):   released (4.3-9ubuntu4)

The gory details are all here:

Hope that helps!


Developers / Re: Device Template using SOAP
« on: September 06, 2014, 04:25:36 am »
Hi beherbie!

I'm self-taught in ruby, so we could have a case of the blind leading the blind here...  :P

thanks for the help!  I know it is close and probably something I am overlooking as I am a noob in ruby.

here is the code

Code: [Select]
soapBody+='<IRCCCode xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">' +key+ '</IRCCCode></m:X_SendIRCC>'

and then to send the key:
Code: [Select]

I suspect an issue with type conversion.  I think you'll have to explicitly force it to string to merge it into the soapBody variable, like so...

Code: [Select]
soapBody+='<IRCCCode xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="string">'+key.to_s+'</IRCCCode></m:X_SendIRCC>'

I also generally don't place spaces between quotes and joined variables for string concatenation;  shouldn't make a difference, but some programming languages are more finicky than others (also prevents hidden line feed characters from sneaking in and causing hair loss  ;) ).

Try that, and see how it goes... Hope it helps!

Good Luck!


Developers / Re: Device Template using SOAP
« on: September 05, 2014, 03:48:09 am »
Hi bherbie!

Why don't you post the code segment and the logs, and maybe we all can figure it out?

Keep fighting the good fight!  You can always bend technology to your will  ;)


Developers / Re: Device Template using SOAP
« on: September 04, 2014, 11:47:15 pm »
Hi bherbie!

Have you seen this thread on Sony SOAP commands?  Might be helpful...,3



Developers / Re: Device Template using SOAP
« on: September 04, 2014, 04:26:52 am »
Hi bherbie!

I'm the author of the ISY994i template (device #2276) which has some SOAP calls.  I only play at being a programmer (more of a SysAdmin/integrator type) so take anything I write with a grain of salt...

My device driver uses GSD.  I have a function to "subscribe" to an events channel, to receive a stream of status events from the ISY controller.  As part of the function, it does a base64 encoding of the Username and password as part of the call (parameters 114 & 115). It looks like this...

Code: [Select]
def subscribeToISY()
# Prepare to send a subscription SOAP request to the device.
# Subscription is a one-way stream of events from the ISY to
# LMCE using the LMCE GSD conn_ method.
$port = device_.devdata_[69].to_s
soapBody ='<s:Envelope><s:Body><u:Subscribe xmlns:u="urn:udi-com:service:X_Insteon_Lighting_Service:1"><reportURL>REUSE_SOCKET</reportURL><duration>infinite</duration></u:Subscribe></s:Body></s:Envelope>'
s = "POST /services HTTP/1.1 \x0D\x0A"
s+= "Host: "+$host+":"+$port+" \x0D\x0A"
s+= "Content-Length: "+soapBody.length.to_s+" \x0D\x0A"
s+= "Content-Type: text/xml; charset=\"utf-8\" \x0D\x0A"
s+= "Authorization: Basic "+auth_s+" \x0D\x0A"
s+= "NT:upnp:event \x0D\x0A"
s+= "SOAPACTION:\"urn:udi-com:service:X_Insteon_Lighting_Service:1#Subscribe\" \x0D\x0A\x0D\x0A"
s+= soapBody.to_s
log("Attempting to Subscribe to ISY Events")
# Attempt to subscribe and retrieve data from the ISY
subscribe = conn_.Send(s.to_s)

I send commands back to the ISY asynchronously using it's REST interface, like so:
Code: [Select]
def sendISYcommand(command)
# This function sends commands to the ISY using it's REST interface.
# Does not use the subscription channel conn_ method.
# Commands are sent asynchronously, and success/fail is returned using
# this function.  Device feedback is received via the subscription.
# $username=device_.devdata_[114].to_s
# $password=device_.devdata_[115].to_s
$port = device_.devdata_[69].to_s
res = Net::HTTP.start($host) {|http|
req =
req.basic_auth device_.devdata_[114].to_s, device_.devdata_[115].to_s
response = http.request(req)
xml_data = (response.body)
debuglog($yellow + "====== / sendISYcommand response body ======" + $grey)
debuglog($yellow + "====== sendISYcommand response body / ======" + $grey)
doc =
s = ""
s = REXML::XPath.first(doc, "RestResponse/status")
if s != nil then
if s.text != "200" then
# Didn't get the HTTP OK :-(  return error code
return s.text
p = ""
p = REXML::XPath.first(doc, "properties/property")
if p != nil then
return p.text
return doc.to_s

Feel free to peruse the code in the template if this looks like something useful for you.  The interesting stuff is in "355 Process Initialize" and "373 Private Method Listing".

The Basic flow of the device start-up is:

355 Process Initialize (all the set-up stuff, calls functions in 373 Private Method Listing).
350 Process Incoming Data (basically, loops processing data coming in from the subscription channel).  Calls functions in 373 Private Method Listing.

Events from LMCE heading outbound to the ISY are serviced by 384 Process Receive for Child, which parses the LMCE commands, formulates the appropriate REST URL , and then calls my function sendISYcommand(command), where command is the URI encoded REST URL.  That code looks like this:

Code: [Select]
cmdId           = cmd.id_                                   # Command ID: ON, OFF, SET LEVEL
cmdTo           = cmd.devidto_                              # Device ID in LinuxMCE
devPort         = device_.childdevices_[cmdTo].devdata_[12] # 12 contains a port/channel
childType       = device_.childdevices_[cmdTo].devtemplid_  # Template ID to know type of device: switch or dimmer

case cmdId
      when 192 #192 is ON                     
           command = "/rest/nodes/#{URI.encode(devPort)}/cmd/DON"
      when 193 #193 is OFF                       
           command = "/rest/nodes/#{URI.encode(devPort)}/cmd/DOF"
      when 184 #184 is Level of dimmer
      dim_level = percenttodecihex(cmd.params_[76])
log("------dce--- Dim Level:" + dim_level.to_s)
           command = "/rest/nodes/#{URI.encode(devPort)}/cmd/DON/#{dim_level}"

response = ""
response = sendISYcommand(command)

You can find the commands you'll be interested in via the LMCE web GUI, under Advanced -> DCE -> Commands.  Look for the media commands.  Hopefully this provides some food for thought...

Good luck with your device driver!


Users / Re: IMPORTANT NOTICE: 1204 debs from svn version 29240
« on: August 16, 2014, 04:21:38 pm »

Any particular things we should be watching for?  The referenced commit was changes to GenDevices and committing Radu's JSON plugin, but the knock-on effects are not as obvious.  Is the area of concern around new dependencies being installed, or changes to existing installed packages/services?



Users / Re: adding more PCI network cards
« on: August 03, 2014, 04:31:01 pm »

This isn't likely to work out the way you want.  Multiple adapters on the same subnet will cause you some real issues with routing, and your network will have some real stability issues.  You generally want one adapter per segment. 

The exception is usually when you need failover (bonding) or link aggregation for increased bandwidth.  There is also the possibility of using a bridged interface across multiple adapters, but LMCE's automation won't handle that, and you're more likely to tear your hair out trying to do it.  BTW, adapter numbering usually starts with 0 in *nix.  (eth0, eth1 for 1st and second adapter).

You may want to pursue a core/edge network switch layout to save yourself a lot of punishment.   Hook your best switch to the internal network adapter on the core, and connect the TV Room and Kitchen to it.  Connect your other switch to the last port on the first switch, and connect other rooms devices to it.

Hope that helps!


Pages: [1] 2 3 ... 14