Universal Powerline Bus (UPB) protocol questions

[BobS0327]

I'm in the process of converting the Universal Powerline Bus (UPB) functionality from an old controller to a Raspberry Pi 2   Right now, I'm in a learning mode in order to fully understand the protocol.  I'm using a simple .Net serial port utility to submit various commands to the PIM and review the PIM responses.
 
What now befuddles me is the Device State Report 0x86,  The protocol document indicates that there can be up to 17 retrieved state information values.  I've determined that Arg1 is the level of brightness.  This value ranges from 00 (off) to 64 (full bright) for a UPB dimmable switch.The question is what do the other 16 retrieved state information variables represent?  I can't find any detailed information what these variable represent.  It's possible I may have overlooked that information somewhere.
 
So, submitting 0710018DFF302C  to the PIM means  report state command  (0x30) for UBP dimmable switch unit 141
 
The PIM will respond with 08001FFD8600E5 where the 00 means that the switch is turned off.  A value of 64 in that position will mean the switch is at full bright.
 
I've included the basic utility that I use to do my testing.  If you wish, you can change the hard coded values to do some experimenting.
 
 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace UPBRaspberry
{
    using System;
    using System.IO.Ports;

    class PortDataReceived
    {
        static byte[] cr = { 0x0D };
        static byte[] ctlt = { 0x14 };
        static byte[] ctlw = { 0x17 };
        public static void Main()
        {
            SerialPort mySerialPort = new SerialPort("COM4");

            mySerialPort.BaudRate = 4800;
            mySerialPort.Parity = Parity.None;
            mySerialPort.StopBits = StopBits.One;
            mySerialPort.DataBits = 8;
            mySerialPort.Handshake = Handshake.None;
            mySerialPort.DataReceived += new SerialDataReceivedEventHandler(DataReceivedHandler);
            mySerialPort.ReadTimeout = -1;
              mySerialPort.WriteTimeout = -1;
            mySerialPort.RtsEnable = false;
            mySerialPort.DtrEnable = true;

            if (!mySerialPort.IsOpen)
            {
                mySerialPort.Open();
            }
            // Place in message mode
            mySerialPort.Write(ctlw, 0, ctlw.Length);
            mySerialPort.Write("70028E");  // Put the PIM in Message Mode.  This variable must NOT be changed
            mySerialPort.Write(cr, 0, cr.Length);
                  
            mySerialPort.Write(ctlt, 0, ctlt.Length);
            mySerialPort.Write("0710018DFF302C"); // Report State Command  (0x30)for unit 141  
            mySerialPort.Write(cr, 0, cr.Length);

            Console.ReadKey();
            
            mySerialPort.Close();
        }

        private static void DataReceivedHandler(
            object sender,
            SerialDataReceivedEventArgs e)
        {
            SerialPort sp = (SerialPort)sender;
            string indata = sp.ReadExisting();
            Console.Write("{0:x}", indata);
        }
    }
}

 
 

 

[pete_c]

@bob
 
I have my Cumulus RPi2 sitting next to an HAI UPB on the second floor here.  That said the UPB PIM is just connected to a Quatech serial server and used for testing mostly here.  The base RPi2 is standard wheezy except for the adds of mono.
 
 
Tell me what to do that I can do in 5 minutes to test your stuff.  Connecting the serial port from the HAI PIM is just moving the cable over to the RPi2.
 
I can today (already tested) run the mono UPB Homeseer plugin by itself and connect to the mothership and it works fine this way.  (IE: mono upb.exe server=mothership)

 

[BobS0327]

Pete,
 
I'm not sure if anything exists that can be used for a test.  I need a test on UPB hardware that provides more than just on/off dimming capability.  This rules out your basic light switches.  But just to give you an example, a UPB controlled humidifier when sent a Get Device State query would not only respond with an on/off state but with other data such as humidity level, fan speed, level of water in the machine, air temperature at the machine etc.  My assumption is that the first variable returned Argv1 is the on/off state and other variables may return the state of other features of the UPB hardware such as humdity level etc.
 
You would need to generate a UPB packet command using the command wizard.  The command would need to be Get Device State.  the Command wizard would generate something like this  <ctrl-t>87040101FF2054<cr>.  Just copy the  string between the <ctrl-t> and <cr> and paste it into the C# util  at the line that has the comment "Report State Command  (0x30) for unit 141".  The copied string should be wrapped in quotes just like the original you will replace.  Next, compile and run the util.  Assuming that the name of the util is test.cs, I would compile from the command line as follows:  CSC.EXE test.cs. When the util is run, it will open a console window and display a response string.  Please send me this string along with your UPB packet command and a detailed description of your UPB hardware and state that the hardware was in when yuou executed the util.
 
My gut feeling is that the other 17 variables are not used but are there for future reference.
 
Pete, thanx in advance for any assistance offered.
 
 
 
 
 
 

 

[ano]

But just to give you an example, a UPB controlled humidifier when sent

Wow, where can I buy one of those? 
 
Yes, its very likely that the other parameters are for future expansion.  The 17 is probably large enough so if they had to, they could send back considerable information. But since there are only UPB dimmers and switches, they are particularly needed. Simply Automated makes a UPB ceiling fan controller, but it doesn't even have the capability to send back fan speed.