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 4 ... 15
16
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!

/Mike

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

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:  http://svn.linuxmce.org/trac/browser/trunk/src/Weather_PlugIn/Weather_PlugIn.cpp

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!

/Mike

18
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
b40>
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
<0xb5fffb40>
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
b40>
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 <
0xb76d4700>
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.

Cheers!

/Mike

19
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 :)

Cheers!

/Mike

20
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. 

http://forum.linuxmce.org/index.php?topic=13775.msg100243#msg100243

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.

Cheers!

/Mike

21
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.

Run
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]
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.5 LTS"
bash:
  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:

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7187.html

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:

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-6271.html
http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-6277.html
http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-6278.html
http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7169.html
http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7186.html
http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7187.html

Hope that helps!

/Mike

22
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]
RemoteKey("AAAAAwAAHFoAAAAWAw==")

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!

/Mike

23
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  ;)

/Mike

24
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...

http://www.remotecentral.com/cgi-bin/mboard/rs232-ip/thread.cgi?171,3

Cheers!

/Mike

25
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
auth_s=Base64.encode64(device_.devdata_[114]+":"+device_.devdata_[115])
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")
debuglog(s.to_s)
# Attempt to subscribe and retrieve data from the ISY
subscribe = conn_.Send(s.to_s)
log(subscribe)
end

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 = Net::HTTP::Get.new(command)
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(xml_data)
debuglog($yellow + "====== sendISYcommand response body / ======" + $grey)
doc = REXML::Document.new(xml_data)
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
end
end
p = ""
p = REXML::XPath.first(doc, "properties/property")
if p != nil then
return p.text
end
return doc.to_s
}
end

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}"
else

end
log(command)
response = ""
response = sendISYcommand(command)
log(response)

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!

/Mike

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

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?

Thanks!

/Mike

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

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!

/Mike


28
Users / Re: Wifi Problems
« on: June 28, 2014, 05:21:36 am »
Hi golgoj4!

Z-wave operates around 900 MHz, so no chance of interference there.  Zigbee (the Hues) operate around 900 MHz in the US, 868 MHz in Europe, and 2.4 GHz in the rest of the world.  So, depending on where you live, the Hues could be a factor.

Also, if you're using WDS (multiple APs with the same SSID), that may also play a factor.  The drops may come from improper handoff between the APs.  If you can get logs or syslog traffic off the APs, that may point towards a cause on that front.

Hope that helps!

/Mike

29
Users / Re: Wifi Problems
« on: June 27, 2014, 04:48:31 am »
golgoj4,

Do you have a Wi-Fi laptop (or AP) with software that can do a wireless site survey?

You may have a lot of nearby devices running on the same channels as you're trying to operate on.  Many people leave their AP's on the default channels, and you can get a lot of congestion on those channels, depending on how close your neighbors are.  Changing the channel on your AP can make a big difference.

Some of the better site survey software will do signal to noise, RSSI, and other quality indicators.  Those can help determine if you have other noise sources around.  Look for poor S/N or low RSSI values, even if the "bars" are high.

Relocating the AP may also help, if you have lots of metal or concrete around it.

Hope that helps!

/Mike


30
Users / Re: Many minor issues
« on: May 31, 2014, 04:04:13 am »
Hi Thom!

From what I had found, the UE was meant to only use cloud music services, not local ones.  LMS wouldn't be able to support the UE radios. 

Squeezebox fans were less than enthused that the UE radio had less features than the Squeezeboxes they were used to, so Logitech added an advanced option to switch to the Squeezebox firmware.

http://forums.slimdevices.com/showthread.php?99027-Smart-Radio-and-Squeezebox-software-upgradability&p=750674&viewfull=1#post750674

I don't have one, so I can't speak to how easy it is, but it just seems like something that a wiki entry could cover.

Hope that helps!

/Mike

Pages: 1 [2] 3 4 ... 15