Parent/child app

Hence, why I'm here!!

Hubitat is what happens when you start with, “what’s wrong with this picture?”, and go from there. Sort of.

2 Likes

I had a moment of hold my breath while BigTalker saved.... And then it saved!!! (Parent app is 3,556 lines of code currently and child is 1,750 lines). I was very intrigued. I hit a bump, but now we've quickly moved on.. I'm impressed.

2 Likes

I don’t know if it would be in your scope or not, but perhaps you could trap these currently not implemented functions (sendNotificationEvent()) and throw a log, auto-convert them to a log.debug() or log.trace() (with an explanation of “Unsupported function…” or just ignore them so they don’t error out and kill apps while their being ported and before you’ve implemented them.

2 Likes

I had the same thought. But, every request like this takes engineering resources to implement and test. So, rather than waste effort on that, we’d rather push what works forward faster. Now you know, no more mystery.

2 Likes

Alright time for the next question…
It seems that there isn’t communication/variable sharing between child and parent app. This worked in ST but it doesn’t seem to be doing so here.

ie:
Parent App

state.appversion = "1.0.0"
def dothisthing(variable1,variable2,variable3){ 
     //The code to do stuff
}

Child App

log.debug "Parent Version: ${parent.state.appversion}"
//do some processing of things
def childvariable1 = "blah1"
def childvariable2 = "blah2"
def childvariable3 = "blah3"
//maybe even more processing of childish things
//send something to the parent function to process:
parent.dothisthing(childvariable1, childvariable2, childvariable3)

Scenario, in BigTalker2, I do most heavy logic in the child app, then once everything is set and ready to go, I call a function in the Parent app, parent.Talk(). It further processes the variables passed to it then does it’s speech thing.

  • Side note, I don’t think this is officially supported in the other hub, but it works. There is a lot of capability that can be derived from parent/child communication. The location object is even used for app to app communication in the other hub (I haven’t used this much except to send data to AskAlexa which is done by sendLocationEvent ( sendLocationEvent(name: "AskAlexaMsgQueue", value: "BigTalker", isStateChange: true, descriptionText: phrase) ), Perhaps Hubitat does these things differently or it can be considered for a future release?

I’m not sure about isStateChange and descriptionText, but sendLocationEvent(name: “xx”, value: “yy”) definitely works.

So does passing parameters from child to parent and parent to child. Rule Machine does that extensively.

I’m going mostly based off of the “null” references in the logs and the fact that calling parent.Talk() doesn’t seem to do anything from the child app to the parent app… If I use the TalkNow() feature which is a parent app only feature then Talk() works, but from the child app, parent.Talk() doesn’t.

2018-02-27 22:12:40.379:tracePARENTCHILDTEST(C2.0.2) || Initialized (Parent Version: null; Child Version: C2.0.2; Group Enabled: true)
2018-02-27 22:12:40.378:traceBIGTALKER2(P2.0.2) || [CHILD:Parent Child Test] Initialized (Parent Version: null; Child Version: C2.0.2; Group Enabled: true)
2018-02-27 22:12:40.312:tracePARENTCHILDTEST(C2.0.2) || Updating settings (Parent Version: null; Child Version: C2.0.2; Group Enabled: true)
2018-02-27 22:12:40.311:traceBIGTALKER2(P2.0.2) || [CHILD:Parent Child Test] Updating settings (Parent Version: null; Child Version: C2.0.2; Group Enabled: true)

When I ported over a parent/child app (MiLight Manager) - I found that the variables were not what was expected…

for instance:

parent.settings.var1

was really:

parent.var1

It didn’t make any sense but it works.

@rayzurbock - if sendNotificationEvent()isn’t implemented, can you add it as a call in your code for now, as a placeholder, and just outputs debug log messages?

Even without notifications and TTS, your app could be useful in the meanwhile to Hubitat using it with speech synthesis hardware.

Heck, I’d love to beta test Hubitat-compatible BigTalker 2 code just to send pre-recorded .mp3 messages on a DLNA speaker!

@rayzurbock

Now that the latest Hub firmware supports Sonos devices any update on you porting over BT2?

I have tested porting BT2 over and for the most part it worked, but works only in speechSynthesis mode (LANNouncer and other devices that process speech locally on the device). It doesn’t work in musicPlayer mode due to the lack of a textToSpeech() function in the Hubitat platform to translate text to mp3 that can be sent to your device (Sonos, etc) to play…

TTS coming soon to a Hubitat near you.

8 Likes

Music (or is that speech) to my ears! :slight_smile:

1 Like

THIS! So much this! As soon as BigTalker is fully ported over to Hubitat I'm completely moving everything over from the old ST! Looking forward to the TTS so I can continue to use the Sonos for output.

1 Like

YES!!! Smartthings went through the slow cloud for TTS so Id walk in, 15 seconds later, "Front Door Open!" Haha!! So looking forward to a local TTS option.

It’s unlikely that any TTS would be local.
Most probably amazon polly

Andy

Well, then to keep it local I'll use it in speech synthesis mode via LanNouncer already installed on an old android phone with a nice speaker connected to it. If that's the trade-off between local and cloud I have no issue with it.

You can always use locally hosted mp3s

Slightly off topic. Anyone got a site where we can download mp3s from.