• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 1 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Node support changed?
#11
Just wait until i properly implemented the new node stuff.

What i'm working on it the following:
- You have Node 1 is the main node with the sender / receiver, some switches, weather stations, and various sensors.
- You have Node 2 which is a child with only some sensors and maybe a relay.
- Node 1 has a unique ID and node 2 as well.

- When you start the main daemon, internally, all devices get this unique ID assigned.
- When you start Node 2, internally, all those devices will also get his unique ID assigned.
- Node 2 will send it's config to node 1 and node 1 merges this config with its own. This results in one big GUI with all devices for all pilight instances.
- When a code has been received, Node 1 will check its unique ID and see if its a sensor of Node 1 or Node 2 and will update the config accordingly.
- When you stop Node 2, it will sync only those config devices belonging to his unique ID and Node 1 will do the same when it's stopped.
- So you have 2 distinct configs, that will be merged when pilight instances are started and will be extracted again when they are stopped.

In my oppinion, this would be the ideal world of nodes.
 
#12
That sounds really nice, except the fact that it's not allways wanted behaviour.
I have various projects where I use pilight, but I don't want to show these up on all the othere pilight instances.

For example : I'm working on a project where I will be switching 8 to 12 relays and reading 6 to 9 temperature sensors and mabey 2 hummidity sensors.
This is a standalone network where I have absolutely no need to see this on a main GUI (the GUI where I switch main living room devices on and off).
So again, please consider making it optional or to disable this behaviour.
 
#13
Quote:This is a standalone network where I have absolutely no need to see this on a main GUI (the GUI where I switch main living room devices on and off).
Then it will automatically be a standalone pilight instance, because pilight is unable to discover its already running instance.

Quote:This is a standalone network where I have absolutely no need to see this on a main GUI (the GUI where I switch main living room devices on and off).
Do you want to see these devices at all in some sort of GUI?
 
#14
(01-08-2014, 11:06 AM)curlymo Wrote: Then it will automatically be a standalone pilight instance, because pilight is unable to discover its already running instance.

I'm sorry .. I didn't write corect what I wanted to say. It should say "This is a standalone project where I have absolutely no need to see this on a main GUI (the GUI where I switch main living room devices on and off)."
So, the project/pilight has nothting to do with other pilight setups but is discoverable in the same subnet.
I intend to use pilight for more of these projects, and I guess other would do so to ?

Quote:Do you want to see these devices at all in some sort of GUI?
No, only for those that I want Smile
 
#15
What about the following options.

I add an standalone option. When using that option. pilight uses the node feature to connect to each other but config files aren't merged.
 
#16
So only updates are sent to every instance (just like the current situation)?
Sounds allready better then *allways* merging, so that would be a yes from me - but I would prefer not sending/receiving when not necessary.

I understand your problem, because you still need the SSDP for local communication, so disabling SSDP is not an option.
Would it be possible to bind SSDP only to 127.0.0.1 when running in standalone mode ?
 
#17
When thinking of it, i'm just fooling around a bit. I will offer a full standalone mode and reintroduce the -S and -P. In standalone mode, ssdp will be disabled and you need to use the -S and -P parameters to communicate with a specific pilight instance.
 
#18
Or use some sort of group id, so pilight instances only connect and sync stuff when belonging to the same group?

Send from tapatalk phone...
 
#19
Could be a nice addition further on.
 
#20
I've added support for sensors / relays connected to different RPi's. Check the git for an explanation or wait for @creamers to update the wiki.
 
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  Windows Support curlymo 35 21,938 06-10-2018, 04:40 PM
Last Post: Leo
  Odroid C2 support on Kernel 4.14 Jojo 5 1,202 06-01-2018, 03:19 PM
Last Post: curlymo
  Mac OS X support andies 4 2,571 12-01-2016, 09:48 PM
Last Post: andies
  Odroid-C1 support terrar 51 24,688 05-31-2016, 11:08 AM
Last Post: Jojo
  Ububtu 14.4 64 bit support terrar 30 14,387 05-09-2015, 11:40 PM
Last Post: curlymo
Question radxa support terrar 57 23,500 01-05-2015, 06:58 PM
Last Post: curlymo
  [Fixed] GPIO at second (clientized) node isn't triggered easy12 12 9,013 04-28-2014, 02:13 PM
Last Post: curlymo
  [Solved] Disabled PHP support error lvdp 4 5,937 02-18-2014, 12:02 AM
Last Post: meloen

Forum Jump:


Browsing: 1 Guest(s)