GENA (General Event Notification Architecture)

Developer's Corner General Dev Discussions
#61

Hi Futzle

I think this is the right spot for this query, since I can’t find a “UPnP Event Proxy” thread (may be one should be started) - anyway:

I wanted to turn on the logging in the proxy. The DLNA player is crashing it occasionally and thought I might catch any errors. I was going to do that by modifying the proxy code and re-uploading it. However it would seem you have to stop the daemon first then upload and then restart the daemon. I see in the doco:

os.execute(“/etc/init.d/upnp-event-proxy stop”)

and this - which I don’t know what it does:

os.execute(“/etc/init.d/upnp-event-proxy disable”)

As Linux is not my area, can you please explain the process for updating the daemon’s code. Long term, it may be useful to have a logging on/off switch available in the proxy UI?

#62

Hi a-lurker,

You’ll need to get to the Vera shell to do this.

Stop the proxy if it is running:

/etc/init.d/upnp-event-proxy stop

Then start it again:

/etc/init.d/upnp-event-proxy start

Leave the shell open and it will print debug information to stdout.

Reloading the Luup interface (LuaUPnP) won’t affect this.

If you have to edit the proxy source, the simplest way is to just re-send it through the web interface, then re-run those two commands. If you know how to SCP and compress plugin files, you could do that too.

The proxy is “outside” the Luup engine which is why I don’t have it write to the LuaUPnP.log file. I could have it write to the Vera syslog instead, I guess. There are other threads on how to send the syslog to a more permanent place.

That “disable” command that you ran will prevent the proxy from starting on the next Vera reboot. The opposite command uses the word “enable”. These two only affect bootup behaviour.

#63

Hi Futzle

Can your proxy do anything with this? It’s spat out by a Yamaha AVR box when the user changes its operation locally using the InfraRed remote control, etc. It goes out to the specified multicast broadcast address.

[code]–[[
NOTIFY * HTTP/1.1
Host: 239.255.255.0:1900
NT: urn:yamaha-com:service:YamahaRemoteControl:3
NTS: yamaha:propchange
USN: uuid:::urn:yamaha-com:service:YamahaRemoteControl:3

<?xml version="1.0" encoding="utf-8"?>

<YAMAHA_AV cmd=“EVENT”>
<Main_Zone>
Power
Input
Volume
Play_Info
</Main_Zone>
</YAMAHA_AV>
]][/code]

Also this Global Cache iTach box has a UDP discovery beacon, as do some other devices:

“UDP packet sent to the multicast IP address 239.255.250.250 on UDP port number 9131.”

It may be useful to see if the device loses power for example (ie no more beacon) .

AMXB<-UUID=GlobalCache_000C1E024239><-SDKClass=Utility> <-Make=GlobalCache><-Model=iTachWF2IR><-Revision=710-1001-05> <-Pkg_Level=GCPK001><-Config-URL=http://192.168.1.100.><-PCB_PN=025-0026-06> <-Status=Ready>

#64

Hi a-lurker,

I did look into having the proxy listen for broadcast notifications. I don’t recall the reason that I didn’t develop it. One possibility is that the (LuaUPnP process on the) Vera is already listening on port 1900, preventing other processes from doing so. I’ll check next time I have command line access to my Vera.

Edit: Yes, that was the problem:

udp        0      0 0.0.0.0:1900            0.0.0.0:*                           21516/LuaUPnP

So without changing the LuaUPnP source (which we don’t have) we are out of luck.

The iTach broadcast thing is doable because it’s on a different port. But the message isn’t SSDP formatted, so there’s almost no code that could be shared. Perhaps that is a different plugin waiting to be written.

#65

The source code for the UPnP Event Proxy is now on GitHub: GitHub - futzle/MiOS-UPnPEventProxy: Plugin for MiOS home automation gateways to subscribe to events from UPnP devices