Arduino USB host get raw events

Based off of your two specifications of

Battery powered (so all items must use minimum power)

WiFi enabled

I would recommend not going with an Arduino at all as it will be much more difficult to meet the minimum power requirement. In order to minimize your power you will need to look into spinning your own board with a very low power microcontroller. It seems like almost every microcontroller company sells some version of ultra low power, but the MSP430 seems to be the most widely used line for low power.

As far as the WiFi enabled part, this is a little bit more difficult to get to be low powered. If you are fine with having your device waking up to check in to see what it needs to do with the LED then you can get your power even lower. However, my guess is that you are actually wanting to be able to send your device a packet at any time to tell it to do something with the LED. In order to go this path with lowest power you would be best rolling your own WiFi solution, but my guess also is that you do not care to do this. So you will want to look for a module that will do this for you. Roving Networks has a few options that support 4uA sleep mode and 38mA active.

With all of that said, if you still want to go with an Arduino (even though you didn't say it was a requirement) you will have to settle for very poor battery life. By very poor battery life I mean something less then a day unless you want to lug around a car battery.

This sounds like it should be easy to diagnose. You say the signals on the RS-485 bus look OK, so check the next point. Keep following the signal until you find it not right somewhere.

The next logical point to test after the RS-485 bus would be when it gets converted back to a single-ended signal that presumably gets presented to UART receive pin of the device. Does that look right? If not, there is a problem with the RS-485 receiver circuitry. If so, then either the device is not working or you have a protocol problem.

In general, it's good to keep dividing up the suspect parts of the system to isolate what is not working, or to test them in isolation. For example, you could either try to tap the UART line into the device and see if you get what is expected by looking at the bytes on a PC with a low level program, or you could try a program on the PC to inject what you think is the right sequence of bytes and see if the device responds as you expect.

Chances are that if the UART signal at the device looks OK (including the obvious issue of baud rate), then you have a protocol problem. In other words, somehow you're not sending the right data to the device. Early on in bringing up a system like this, I often use a low level test program on the PC that sends and receives individual bytes. I can type byte values in decimal, hex, and as ASCII character, and it displays everything it receives likewise. This can be very useful for verifying that you really do understand the protocol the device expects.

Do some of these experiments and tell us what you find. It would also help to provide some information on this device you are trying to talk to from the micro.