From: rickerdo <ric...@sa...> - 2014-01-09 14:37:39
|
I've been going through much of the same pains as well, and couldn't agree more about creating a structured object model for all devices that would require them. Being able to have a $thermostat object that could return multiple "child" objects/states via JSON would be awesome. Imaging something like: { "thermostat1" : { "category" : "HVAC", "type" : "Thermostat_Item" "tstat_modes" : { "1" : "cool", "2" : "heat", "3" : "auto", }, "tstat_mode" : "cool", "fan_modes" : { "1" : "on", "2" : "off", "3" : "auto", }, "fan_mode" : "auto", "fan_state" : "on", "hold_state" : "off", "temp" : "71.0", etc... } } Such a structure could have been a huge help now that I've moved onto a touch screen interface for my Media Room using Control Fusion's iViewer. I wanted a fairly simple way to report back status of my receiver, among other things, so I created a Socket_Item named $denon1 (which had to be tied to a Generic_Item named $receiver), but that tracked too many states (power, source, mute [on|off], volume, etc...). I was looking for a way to track each of those "child objects" separately. So I ended up having to create separate Generic_Items named: $receiver_pwr, $receiver_src, $receiver_mute, $receiver_vol. These items are changed by parsing the state changes of the $denon1 Socket_Item. It's a bit of a kludge, but it works well enough for now. I also wanted a way of pushing state changes to my tablet running iViewer, so I created this little sub routine: sub send_JSON { my $json = new JSON; my $obj = get_object_by_name(@_); my %obj = %$obj; # "unbless" $o, because it's an object? my $json_txt = $json->encode( \%obj ); $telnet_server->set("$json_txt\n\r") if active $telnet_server; } ...then I simply call the sub wherever a state may change like: # Get output from receiver if (my $denon_data = said $denon1) { print_log "[init-receiver] \$denon_data: $denon_data" if $denon_debug; if (exists $denon_responses{$denon_data}) { my $den_res = $denon_responses{$denon_data}; print_log "[init-receiver] Got a match for: $den_res" if $denon_debug; # Set $receiver_pwr if ($den_res =~ m/^(on|off)/) { $receiver_pwr->set_now($den_res) ; send_JSON("receiver_pwr"); print_log "[init-receiver] \$receiver_pwr STATE: " . $receiver_pwr->state; # Set $receiver_src } elsif ($den_res =~ m/^input/) { $receiver_src->set_now($den_res); send_JSON("receiver_src"); print_log "[init-receiver] \$receiver_src STATE: " . $receiver_src->state; # Set $receiver_mute } elsif ($den_res =~ m/^mute/) { $receiver_mute->set_now($den_res); send_JSON("receiver_mute"); print_log "[init-receiver] \$receiver_mute STATE: " . $receiver_mute->state; # Set $receiver_vol } elsif ($den_res =~ m/^vol/) { # Need to define volume changes $receiver_vol->set_now($den_res); send_JSON("receiver_vol"); print_log "[init-receiver] \$receiver_vol STATE: " . $receiver_vol->state; } # Send a fake JSON message for all non-defined sources } elsif ($denon_data =~ m/^SI/) { print_log "[init-receiver] \$denon_data: $denon_data is not defined. Sending undef in JSON..."; $telnet_server->set('{"object_name":"$receiver_src","state":"undef"}' . "\n\r") if active $telnet_server; } } Also, whenever iViewer establishes a connection to MH, the button states are updated with: if (active_now $telnet_server) { my $client_ip = $Socket_Ports{server_telnet}{client_ip_address}; print_log "[media_room_AV] Detected new connection from $client_ip. Sending pwr and src states"; send_JSON("theater_pwr"); send_JSON("receiver_src"); } All of this allows me to manually change sources on the receiver and have the changes reflected on the tablet near real time without the tablet having to constantly poll MH. I'm not trying to plug iViewer, but once I started messing around with JavaScript (it's native language), I realized it's just as flexible on the touchscreen side as MH is on the automation side. MH and CF's iViewer would be a perfect match, if only an easier to manage data structures existed within MH. As it stands though, the hurdles require a LOT of coding on the MH side. Thankfully, MH is flexible enough to allow such changes, but it would be nice if they existed natively. -- View this message in context: http://misterhouse.10964.n7.nabble.com/Question-related-to-JSON-calls-to-MH-tp19223p19235.html Sent from the Misterhouse - User mailing list archive at Nabble.com. |