maybe you can provide a more detailed bug report, e.g. what exactly you're doing. Are there any messages in syslog? Adding devices to rooms works fine (we've no other reports that indicate otherwise). But for the records, this is the old web admin written in cherrypy. The new interface is served via agorpc on port 8008. Just make sure to install the latest package.

OK, after updating my svn copy and running the updated agosimulator.py it doesn't go kablooey anymore. It appears that was what tripped it.

afaict yes

Well... it still blows up, but slightly differently. I get the error only 50% of the time now, and refreshing the page gets me my page back without having to restart everything.

Code:

An error occured in a template

/opt/agocontrol/admin/agoadmin.py:231    default     inventory = discover()
/opt/agocontrol/admin/agoadmin.py:79     discover    if message.content:

Where exactly can I see this emberjs thingy?

Well... that idea came out of something else really. I'm going to abuse these light switches to trigger scenarios. Variable substitution is serious overkill on the client side (Whisperer) and they never change EAs once configured. While thinking how to do this, this crossed my mind: "dude, these switches are like tiny fixed-layout Orbiters".

All this because otherwise I'd have to add about 9 of these, with 9 scenarios each, and the prospect of RSI doesn't please me

Soooo, did anything happen in the past month or so?

Of course not. That would go against our collective beliefs.

But just today I got a brilliant (for various definitions of "brilliant") idea that will probably become useful. I'm thinking of extending the "Execute Command Group" command that the DCERouter can handle to include user-specified and server-specified variables, a la Orbiter's SubstituteVariables.

Here's how it looks like:

You have a scenario that says "MH Play Media" with a parameter called "Entertainment Area" that has a value of "<%=E%>". That would normally be substituted by either OrbiterGen or the Orbiter (not sure which, don't want to check right now) to form a proper command.

So... I want to do this:

Execute Command:
PK_CommandGroup = 1
Variables: C:EA=2, where C is for "Client", EA is for "Entertainment area"

but also be able to use a S:IP variable in the scenario should I need it for whatever reason, where S is for Server, and IP is the Core's IP address.

Another potential variable that crossed my mind: S:MyEA - where the client just doesn't want to bother with looking up its own EA or Room, for various reasons (like it's not very economical for it, but really cheap on the Core).

An Orbiter would be able to operate sans-OrbiterGen, using only "Execute Command Group". You'd probably lay it out by dragging scenarios from a palette on the side or something. The Orbiter would be one way until a back channel is implemented (shouldn't be that hard if you know where to look and write a very generic data source counterpart of "Execute Command Group" - if there isn't one already of course).

Not very efficient, but it works.

Suggested efficient version of script:

Code:

#!/bin/bash

# This script looks for Apple devices on the network and does something
# for every device that it finds.

if [[ $1 != "background" ]] ;then
        echo "Backgrounding ..."
        screen -d -m -S "AppleRadar" "$0" "background"
        exit 0
fi

## Loging function
function Log() {
        #echo "$(date) $*" >> /var/log/pluto/AppleScanner.log
        echo "$(date) $*"
}

apple_macs=( 00:03:93 00:0a:27 00:0a:95 00:0d:93 00:11:24 00:14:51 00:16:cb 00:17:f2 00:19:e3 00:1b:63 00:1d:4f 00:1e:52 00:10:fa 00:1e:c2 00:1f:5b 00:1f:f3 00:21:e9 00:22:41 00:23:12 00:23:32 00:23:6c 00:23:df 00:24:36 00:25:00 00:25:4b 00:25:bc 00:26:08 00:26:4a 00:26:b0 00:26:bb 00:3e:e1 00:c6:10 00:f4:b9 04:0c:ce 04:1e:64 04:54:53 0c:74:c2 0c:77:1a 10:40:f3 10:93:e9 10:9a:dd 14:5a:05 14:8f:c6 18:20:32 18:34:51 18:e7:f4 1c:ab:a7 24:ab:81 28:37:37 28:6a:b8 28:6a:ba 28:cf:da 28:e0:2c 28:e7:cf 34:15:9e 34:51:c9 3c:07:54 3c:d0:f8 40:30:04 40:3c:fc 40:6c:8f 40:a6:d9 40:d3:2d 44:2a:60 44:d8:84 48:60:bc 4c:b1:99 50:ea:d6 58:1f:aa 58:55:ca 58:b0:35 5c:59:48 60:33:4b 60:c5:47 60:fa:cd 60:fb:42 64:20:0c 64:b9:e8 64:e6:82 68:09:27 68:a8:6d 6c:c2:6b 70:73:cb 70:cd:60 70:de:e2 74:e1:b6 78:a3:e4 78:ca:39 7c:11:be 7c:6d:62 7c:c3:a1 7c:c5:37 7c:f0:5f 88:c6:63 8c:58:77 8c:7b:9d 90:27:e4 90:84:0d 98:03:d8 98:d6:bb a4:67:06 a4:b1:97 a4:d1:d2 b8:17:c2 b8:8d:12 b8:c7:5d b8:f6:b1 b8:ff:61 c0:84:7a c4:2c:03 c8:2a:14 c8:33:4b c8:bc:c8 cc:08:e0 d0:23:db d4:9a:20 d8:30:62 d8:9e:3f d8:a2:5e dc:2b:61 e0:b9:ba e0:f8:47 e4:ce:8f e8:04:0b e8:06:88 ec:85:2f f0:b4:79 f0:cb:a1 f8:1e:df fc:25:3f 00:88:65 04:15:52 04:26:65 04:f7:e4 10:1c:0c 10:dd:b1 1c:e6:2b 20:7d:74 28:cf:e9 2c:b4:3a 30:90:ab 30:f7:c5 34:c0:59 38:0f:4a 38:48:4c 3c:e0:72 40:b3:95 44:fb:42 4c:8d:79 54:26:96 5c:96:9d 60:fe:c5 64:a3:cb 68:9c:70 70:11:24 78:6c:1c 7c:fa:df 80:92:9f 84:fc:fe 88:1f:a1 88:53:95 88:cb:87 94:94:26 98:b8:e3 9c:04:eb a0:ed:cd a8:96:8a a8:fa:d8 ac:3c:0b b4:f0:ab b8:78:2e bc:3b:af bc:92:6b c8:6f:1d cc:78:5f d8:00:4d d8:d1:cb e4:25:e7 e4:8b:7f e8:8d:28 f0:d1:a9 f4:1b:a1 f4:f1:5a )

declare -A apple_macs_assoc

for mac in "${apple_macs[@]}"; do
    apple_macs_assoc["$mac"]="$mac"
done

while : ;do


        while read serverIP skip serverMAC skip; do
                #sleep 10
                ## Get the important info

                Log "Processing $serverIP (mac: $serverMAC )"

                if [[ -n "${apple_macs_assoc["$serverMAC"]}" ]]; then
                    Log Found an apple product here: $serverIP
                    break;
                fi

        done < <(arp -n |fgrep -v incomplete |fgrep ether)

        ## Wait 60 seconds before doing another scan
        sleep 60
done

I haven't thoroughly tested my new script, but it appears to be doing what the original one did.

My plan is to port the AgoControl schema functionality to LinuxMCE. It shouldn't need any changes, but I'm yet to learn it. After that, whatever gets written should work on both simultaneously (fingers crossed).

So what you want is to create your device template, fill in the MAC address and let DHCP Plugin do its thing when the fruity gadgets request their IPs? Is that it?

Well... so far I'm stuck with AgoControl, because setting a room for a device crashes AgoAdmin It crashes after it saves, so a restart of the services brings everything back, but it's quite annoying, so I'll wait for it to get fixed.

Well, totallymaxed initial statement hinted at: Dianemo will develop stuff inhouse, and once ready will open it for others, as opposed to what you are saying now...

totallymaxed is a bit overenthusiastic about it We don't have the manpower. All I can do is get this ball rolling and hope it snowballs.

We ran some very basic experiments, using dummy, ad-hoc data and structures. I was hoping another guy we know would be able to help out. He can't, on grounds of inexperience. This idea came about after I started working with HTML5 and jQuery for an unrelated project, then remembered the iOrbiter... which isn't that fancy, but it's acceptable in some environments. The idea was that I write some stupid UI using HTML5 and AJAX so there's a starting point, and then hand it over to whoever to continue it, 'cause I have a lot of other work to do

Yes, I understand what and why you guys are doing this, but by doing this, you're fragmenting developer resources even more than what we already have!

You mean people that don't have the skills to help out in other areas will become scarce, so you'll have smaller numbers of people who can't code in other areas on interest?

So basically, you're keeping this under wraps, until you're "ready" to show it off. Throwing it over the wall.

What wall? We haven't even started any code yet. We're... err... talking about it We're having meetings about what we should discuss in our meetings

The plan is to start something, no matter how stupid, and hope people like polly take over once we have an idea about what we're getting into. Then we get a github repository or ninety (such is git ).

there is a simulator available, it will provide some fake devices. Ping me on IRC when you're going to have a look, I'll be more than happy to assist. Just be warned that the current resolver component was rewritten in c++ and still has some issues. There is a python one, too, which is quite stable already.

* uplink likes Python

yes, there are other methods besides "message". Regarding the inventory, that is only fetched at the first load. You'll get notifications for changes when you subscribe to them on ago control. When listening to the proper events you can keep it up to date without needing a "reload". With standard I mean this: http://www.jsonrpc.org/specification
Adhering to it allows clients from multiple languages to talk to the service without much hassle. You can e.g. batch requests and have a defined set of result codes. Anyway..

OK, I'll fold (for now?). The main purpose is to see where an HTML5 Orbiter can get us. If it's JSON-RPC that will be the information transport method, then so be it. I'll install Ago Control in a Virtualbox some time and have a play with it in the following days or so, then attempt to whip up a crude web interface for it.

Do you have any virtual devices I can configure? Or are they easy to make? I don't have any physical devices I can use with Ago Control right now, so a few fake ones (like, say, Upnp_Light) would be helpful

Inventory command is OK. RESTful /what/ever/path/to/object doesn't interfere with it, it can just provide reduced sets when needed, rather than transferring a full schema all the time (reload Orbiter? ). Both can co-exist on top of the same data layer.

I don't like the JSON-RPC structures because you have to wrap the useful data with extra crud that stays fixed. Are you planning to set request.method to anything else but "message"? Because only request.params contains useful information, and that's pretty much what I've exemplified. Any reason not to pass just the contents of request.params around?

I assume that you have libs that do json_rpc_call($method, $params), that's why you say it's "standard". So is ad-hoc JSON then The params are that ad-hoc JSON anyway. The method can go in the URL. I'd say that would be a lot more readable and properly separated. But that's just me. Hell, you could tail the web server log and see what commands are coming in (without their parameters), just to make sure you're sending the right commands or that the commands get to the server - helpful if your server isn't sitting there idle just for you and you need to grep the tail.

So, what I'm suggesting would look like this with jQuery for the example you gave:

Code:

$.ajax({
  url: '/message',
  method: 'POST',
  data: {
    command: 'setlevel',
    uuid: uuid,
    level: level
  },
  onSuccess: function() { do_my_thing(); },
  onError: function() { moan_loudly(); }
});

RESTfully, it would look like this I guess:

Code:

$.ajax({
  url: '/' + uuid + '/setlevel',
  method: 'POST',
  data: {
    level: level
  },
  onSuccess: function() { do_my_thing(); },
  onError: function() { moan_loudly(); }
});

Now that I wrote the second one, it does look a tiny bit uglier, because I have to compose that URL Hmm... But neither is uglier than JSON-RPC so far.

totallymaxed, please use jquery as JS library, i'm sick of all the other JS libraries ....

;-) ...

No argument here: jQuery is what will be used.

It appears I need to take a look at this Ago Control thing to see what it can do Bolting new features onto Pluto is getting a bit old.

Can it play media? If not, does it have the infrastructure in place? If not, I have a few ideas of my own - just not the time, or I'd jump right in.

The JSON-RPC interface can be designed in such a way that it's the same for both LinuxMCE and Ago Control. The way I see it, it should present high-level objects, and avoid providing access to the low level infrastructure as much as possible.

I'm still to invent what the data exchange protocol should look like, but I'm sure it has to NOT look like what's in the Ago Control wiki.

Here's a quick example I'm inventing as I'm writing it:

Request:

Code:

GET /lights/list

or:

Code:

GET /lights/list/+room/<id>

Reply:

Code:

{
  "lights": [
    {"id": "<id1>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"},
    {"id": "<id2>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"},
    {"id": "<id3>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"}
  ]
}

Request:

Code:

POST /lights/<id1>

{
  "power": <on|off>,
  "level": <0..100>
}

Reply:

Code:

HTTP/1.1 200 OK

Request:

Code:

GET /lights/<id1>

Reply:

Code:

{
  "power": "<on|off>",
  "level": "<0..100>"
}

That doesn't look like JSON-RPC. It's plain new RESTful. That's what I'd like to have. Essentially, the HTML5 Orbiter I have in mind won't be very different from a Web 2.0 web service.

As usual, I lack the time. While Andy made it sound like an HTML5 Orbiter is my main priority right now, that's not the case. I have some ideas, and I was hoping somebody else around here had enough knowledge to work on it, but I found out, after a few trials, that the person in question has a very steep mountain to climb first in terms of knowledge.

The concept is very promising. It just needs resources.