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 ... 13
1
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

2
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

3
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

4
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

5
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

6
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


7
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

8
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


9
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

10
Users / Re: Many minor issues
« on: May 30, 2014, 03:30:38 pm »
5. I don't think the "new" squeezebox radio is branded as such, but it looks almost the same.

It's called the Smart Radio UE, and runs a different firmware for their streaming services.  A "downgrade-able" firmware is available to restore compatibility with the Logitech Media Server (aka Squeezebox Server).  More info can be found in the Squeezebox Radio forum http://forums.slimdevices.com/forumdisplay.php?32-Squeezebox-Radio

I thought about getting one, but decided to just go with Raspberry Pi's. That way, I can use them for Airplay and as Squeezeslaves, and add home automation to the mix using AgoControl (as sensor platforms as well as maybe running LED lights via OpenDMX).  Still playing with it at this stage.

You might want to look into SqueezePlug, a ready to roll distro for the RaspberryPi.  http://www.squeezeplug.eu

Hope that helps!

/Mike

11
Users / Re: Core/Hybrid Dual NIC's Dual MTU speeds.
« on: May 29, 2014, 04:47:19 pm »
Pigdog,

Jumbo frames don't generally work well in mixed environments.  Usually, you use jumbo frames on network segments that don't have to route anywhere (vMotion, FCoE, dedicated storage network, backup network, backend networks, etc).

What's happening is the jumbo frames are having to be broken down when routed through the core, re-transmitted, and the received traffic will have to be chunked together to make new jumbo frames to send back to the MD's (incurring significant latency).  Needless to say, performance will suck royally (especially on commodity hardware).

You may wish to reconsider your usage strategy for jumbo frames...

If you choose to keep using them, you may wish to investigate/verify that your MD's are using the Apt-proxy and a http caching proxy, and you'll likely need to do some serious Kernel network performance tuning...

/etc/sysctl.conf
Code: [Select]
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.optmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216

The above is a place to start, and can be used on both core and MD's (even without jumbo frames).  It sets 16M buffers for the network, presuming 1Gbe network adapters.  I run those settings on my network without issues.  The kernel defaults to 1M and 4M buffers, which are more suitable to 100M network adapters.

Here's another place to look for ideas...
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Welcome%20to%20High%20Performance%20Computing%20%28HPC%29%20Central/page/Linux%20System%20Tuning%20Recommendations

Just keep in mind, you won't be able to avoid the fragmentation issues; you may just be able to mitigate them to a tolerable extent.  It looks like you like to play, so I figured I'd point you towards some places to start...

HTH!

/Mike

N.B.  The IBM wiki page above also has tuning parameters for 'ib', which are Infiniband adapters. Disregard unless you actually have an Infiniband fabric in your house...

12
Users / Re: old server proliant ml530 G1
« on: May 21, 2014, 02:03:27 am »
Joerod,

Speaking as a server guy, your "free" server may end up costing you in the long run.  It's a circa 2001 Dual-processor Pentium 3, with 133MHz (not GHz) RAM, Ultra SCSI 3 drives, 100M ethernet, and PCI/PCI-X slots all in a 7 RU chassis.  No offense intended, but these days we call that a 13 year old space heater.  The amount of compute capability vs the amount of power being used is quite disproportionate compared to even inexpensive modern hardware.  To be perfectly honest, most modern smartphones have more horsepower...

I don't want to dissuade you from using it, but you may want to set your expectations appropriately... Also, keep in mind that if you start to use it for "production" purposes at home, you are running a higher level of risk.  Your likelihood of getting spare parts is slim, and those disks are around 13 years old.  In the enterprise space, 3-5 years is considered old for disks, and 5-7 is considered old for server hardware.  New hardware uses less power and has on-average double the performance of two years previous.

Just wanted to set your expectations relative to your hardware's capabilities...

Hope that helps!

/Mike

13
Users / Re: Proxy Orbiter crashing (Re: web orbiter refresh)
« on: March 11, 2014, 04:21:47 am »
Code: [Select]
#!/bin/bash
kill -KILL  `ps ax|grep Proxy_Orbiter|grep log|cut -b1-5`

Works a treat for me.
Sweeeeet!  Worked like a treat for me too!  That restarts them properly; now to figure out what's breaking them in the first place...

Thanks Posde!  Much appreciated!

/Mike

14
Users / Proxy Orbiter crashing (Re: web orbiter refresh)
« on: March 06, 2014, 07:36:10 pm »
Hi Folks!

Not to hijack the thread; is the web orbiter code also used for the Proxy Orbiters (like for Roaming Orb)?  I have problems with those just dying, and having to reboot the core to get them to work.  Happens in both 10.04 and 12.04.

Now back to your regularly scheduled discussion thread...  ;)

/Mike

15
Developers / Re: New Template ISY994i uploaded
« on: March 05, 2014, 04:31:09 am »
Hi Phenigma!

Another question, did the mysql-ruby dependencies ever get added to the device template? 

Not yet; I plan on adding it in the next round of updates.  I'm working on integrating the ISY's WeatherBug module with Thom's Weather plugin, and updating some hardware support.

Thanks for following up on this!

/Mike

Pages: [1] 2 3 ... 13