multiple config files for nodes

[mknx]

read multiple config files from the 'nodes' directory.

[2ndsky]

I looked at your code in the nodes_config branch. The idea of dictionary concatenating is nice. When I executed the code with two sample configs I got problems with the access of values. I defined two configs:

1.conf:

['living_room']
    [['temperature']]
        type = num

    [['light']]
        type = bool

2.conf:

['kitchen']
    [['tv']]
        type = bool

If I try to update a sub node with the CLI I cannot use the path version like "up living_room.light = True" instead I have to use "up light = True". The corresponding logic isn't triggered as well:

if not sh.living_room.light():
    sh.kitchen.tv('off')
if sh.living_room.light():
    sh.kitchen.tv('on')

Another problem is, that you cannot define a node in two different config files. Let's say you want to have each floor in a separate config file with a structure like that:

['floors']
    [['eg']]
        ...

and another one with:

['floors']
    [['dg']]
        ...

you end up with two nodes called "floors". Okay, this is maybe not the best example, but spreading a node over several config files could be very useful in some cases.

What do you thing?

[mknx]

Thanks for testing and the bug report. I've fixed it.

Another problem is, that you cannot define a node in two different config files.

I don't see it as a problem. I see the point spreading a node over several config files. You want to avoid work for import scripts? Don't you? ;-)
But I really like complete and independent config files.

[2ndsky]

I can understand your point with one file per node. It's okay for me I just want to mentioned it. I'll test your fix asap.

[mknx]

If you don't find another bug would it be ok to merge the branch into master?

[2ndsky]

It depends, will we use the master as release branch or just as bugfree deployable branch? Or do you want to release it as version 0.7 already? For me this will be fine. I mean the new config format with splittable config files and an arbitrary depth is a great advantage and so other users can test it as well.

[mknx]

I see the master branch as a stable deployable branch.
No, I won't release it right now. No release without testing and documentation. I'm going to merge the changes into master and test this version on my production system.
After that I would start documenting the changes and features and switching the homepage to: http://mknx.github.com/smarthome/ (gh_pages branch).
What do you think of a feature freeze for master?

[2ndsky]

Please be so kind and merge it into the develop branch too and overwrite my commit from yesterday. I will test it this weekend on my production system as well. Feature freeze for 0.7 is okay for me.

[mknx]

I've reset the develop branch to master (with 'git rebase master develop')

[2ndsky]

I tested the new code over the last weekend on my production machine at home. The structure and access functions work like a charm but I had issues with the logics. They were not triggered by changes from the watch items. If I trigger the logic by hand everything works fine. Do I have to put the "sh" in front of the watched items when I define the logics? In the old version it works without. I didn't took a deeper look on that but I will if you have no idea what could be the problem.

[mknx]

have you specified 'watch_item' or 'watch_node'? But don't bother to change it to 'watch_node' I would like to revert the name change of items to nodes. One reason is to avoid changes for the end user and the second reason is to reserve the keyword 'node' for a potential ha plugin.
P.S items are listet without the 'sh.' in front.

Update: typo

[2ndsky]

Okay, didnt see that this property was changed. Now eanything works like expected, thanks.