[DEPRECIATED] Orbit Bhyve Controller - Hose Faucet Timer Integration SmartApp

SmartApps & Automations Community Created SmartApps
,
82

Why do you have “water_volume_gal” instead of “cycle_volume_gal”? Is there more than one API or, is it written differently?

I am not that experienced in SmartApp writing but I do design some good looking DTH’s. Where are the url’s that you use to connect to the API server? That’s always baffled me about SmartApp writing.

BTW, I have a manual timer from webCoRE running right now (without your api, just saw it), and it’s not updating gallons on your dth. Hopefully that changes with the API.

I noticed some weird behavior in the MQTT as well, it will only start counting gallons once I press the center of the ring on the app to show gallons.

84

@kurtsanders

I notice you got the code from billchurch. I was using the same code. :slight_smile:

What does this mean?

“topic: bhyve/device/5ee3b4ec4f0cde3efe8a33cf/refresh message:
Mon, Jun 15, 2020, 10:34:45 AM - RECEIVED parseMessage topic: ‘bhyve/device/5ee3b4ec4f0cde3efe8a33cf/refresh’ - message: ‘’
Mon, Jun 15, 2020, 10:34:45 AM - refresh
Mon, Jun 15, 2020, 10:34:45 AM - All 1 devices are reporting a ‘CLOSED’ state’
Mon, Jun 15, 2020, 10:34:45 AM - Sending PushOver ‘Mon, Jun 15, 2020, 10:34:45 AM - All 1 devices are reporting a ‘CLOSED’ state’’
Mon, Jun 15, 2020, 10:34:45 AM - All Devices -> POSTING Device Updates to SmartThings API
Mon, Jun 15, 2020, 10:34:45 AM - All Orbit Devices -> Executing Client.prototype.smartthings for event: UPDATEALLDEVICES
Mon, Jun 15, 2020, 10:34:45 AM - Orbit Error: TypeError: Cannot read property ‘1’ of null
Mon, Jun 15, 2020, 10:34:45 AM - Pushover encountered a severe error: Error: Request failed with status code 400
Mon, Jun 15, 2020, 10:34:45 AM - Error: Request failed with status code 400
at createError (/home/tony/bhyve/node_modules/axios/lib/core/createError.js:16:15)
at settle (/home/tony/bhyve/node_modules/axios/lib/core/settle.js:17:12)
at IncomingMessage.handleStreamEnd (/home/tony/bhyve/node_modules/axios/lib/adapters/http.js:236:11)
at emitNone (events.js:111:20)
at IncomingMessage.emit (events.js:208:7)
at endReadableNT (_stream_readable.js:1064:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickCallback (internal/process/next_tick.js:180:9)
Mon, Jun 15, 2020, 10:34:45 AM - Orbit Error: Error: Request failed with status code 400”

If it’s for PushOver I disabled it in the .env.

85

Yes, Bill provided a nice code base for the raw bhyve mqtt websocket connection and he is credited in the program for it… I enhanced his base code significantly and added all the integration to my SmartThings Orbit bhyve Controller and Pushover Messaging for those who wanted that messaging service.

Interesting set of errors, I see that there is an error before the Pushover section:

Mon, Jun 15, 2020, 10:34:45 AM - Orbit Error: TypeError: Cannot read property ‘1’ of null

In the orbit.js, this line below should prevent any calls to the Pushover service if set to false in the .env. I thought it was a boolean but now see that it a STRING, so I have UPDATED the orbit.js file in the github node repo version 0.0.2 to correct that error with single quotes around ‘false’ as below!

if (process.env.PUSHOVER_MESSAGING==‘false’) {return}

The .env file should have:

PUSHOVER_MESSAGING=false

and the command to start (assuming bhyve folder):

node -r dotenv/config app.js dotenv_config_path=/home/pi/bhyve/.env

86

Looks like you have been busy…

  1. I use the bhyve API json variable water_volume_gal to get the approximate usage rate when the watering device is active. This value is all over the board as the watering device cannot measure low flow rates. I’m not sure what is the difference between water_volume_gal and cycle_volume_gal
  2. The bhyve URL’s are in the Orbit Bhyve SmartApp code. Best to start there.
  3. Glad to hear using WebCore, great app. I’m not sure about what you are trying to do here, but if it works for you - Great!
  4. Yep, something is causing the connection to the bhyve websocket server to unexpectedly abort at different timing intervals and I have PM2 restarting it. But this constant restarting is not what I desire in a stable proxy, so I am researching what to do to detect and handle since node.js aborts easily. If you have enhancements to this proxy server, feel free to send them my way for integration into the node.js code stream.
87

1.) On the json response when the water is running, I don’t even see water_volume_gal, it’s only cycle and I’m using the same MQTT agent, pretty much. Quite odd. They probably have the same value.

2020-06-15T02:07:57.667Z - event: flow_sensor_state_changed
2020-06-15T02:07:57.667Z - message: {“flow_rate_gpm”:2.2181599999999997,“cycle_run_time_sec”:1796,“stream-id”:“str_id”,“event”:“flow_sensor_state_changed”,“cycle_volume_gal”:50.25629,“device_id”:“dev_id”,“client-topics”:[“device-clients-1”],“timestamp”:“2020-06-15T02:07:56.000Z”,“gateway-topic”:“devices-1”}
2020-06-15T02:08:01.679Z - message: {“timestamp”:“2020-06-15T02:08:00.000Z”,“event”:“watering_complete”,“stream-id”:“str_id”,“client-topics”:[“device-clients-1”],“gateway-topic”:“devices-1”,“device_id”:“dev_id”}
2020-06-15T02:08:01.679Z - event: watering_complete
2020-06-15T02:08:01.679Z - message: {“timestamp”:“2020-06-15T02:08:00.000Z”,“event”:“watering_complete”,“stream-id”:“str_id”,“client-topics”:[“device-clients-1”],“gateway-topic”:“devices-1”,“device_id”:“dev_id”}
2020-06-15T02:08:02.243Z - message: {“event”:“change_mode”,“mode”:“auto”,“device_id”:“dev_id”,“timestamp”:“2020-06-15T02:08:01.000Z”}
2020-06-15T02:08:02.244Z - event: change_mode
2020-06-15T02:08:02.246Z - message: {“event”:“rain_delay”,“delay”:0,“device_id”:“dev_id”,“timestamp”:“2020-06-15T02:08:01.000Z”}
2020-06-15T02:08:02.247Z - event: rain_delay
2020-06-15T02:08:02.247Z - message: {“event”:“rain_delay”,“delay”:0,“device_id”:“dev_id”,“timestamp”:“2020-06-15T02:08:01.000Z”}
2020-06-15T02:08:02.247Z - message: {“timestamp”:“2020-06-15T02:08:01.000Z”,“event”:“device_idle”,“stream-id”:“str_id”,“client-topics”:[“device-clients-1”],“device_id”:“dev_id”}
2020-06-15T02:08:02.247Z - event: device_idle
2020-06-15T02:08:02.247Z - message: {“timestamp”:“2020-06-15T02:08:01.000Z”,“event”:“device_idle”,“stream-id”:“str_id”,“client-topics”:[“device-clients-1”],“device_id”:“dev_id”}

2.) I read that SmartApp code more than 5 times last night and didn’t see any evidence of a url.

3.) I have a notification based on your DTH, when gallons return to 0 it will stop ‘setting’ the cycle variable, add the cycle local variable to the sprinklergallons global variable and put it in a spreadsheet and give me a Tasker Notification of the cycle and total month to date.

I live in Phoenix, we take our watering seriously if we want to have a decent looking yard in the summer time.

Thanks for the way to disable pushover, it was not in the .env-sample file that is on git. Or, at least I didn’t see it.

Hopefully I can read over the code a little later this evening and see what I can help with.

88

Mon, Jun 15, 2020, 6:59:35 PM - watering_events error: TypeError: Cannot read property ‘1’ of null
Mon, Jun 15, 2020, 6:59:35 PM - Orbit Error: watering_events: TypeError: Cannot read property ‘1’ of null

Still getting the null.

BTW, I reinstalled the package. You might want to change:

tar -xvf st-orbit-bhyve-controller-0.0.1.tgz --strip-components 1
ls -la

To this:

tar -xvf st-orbit-bhyve-controller-0.0.2.tgz

In the readme.md. Otherwise, it won’t install.

89
  1. Here is the section in orbit-bhyve-controller.groovy smartapp that has many of the API calls…
String orbitBhyveLoginAPI() 	{ return "https://api.orbitbhyve.com/v1/" }
Map    OrbitBhyveLoginHeaders() 	{
    return [
        'orbit-app-id':'Orbit Support Dashboard',
        'Content-Type':'application/json'
    ]
}

def OrbitGet(command, device_id=null, mesh_id=null) {
    def respdata
    def params = [
        'uri'		: orbitBhyveLoginAPI(),
        'headers'	: OrbitBhyveLoginHeaders(),
    ]
    params.headers << ["orbit-api-key"	: state.orbit_api_key]
    switch (command) {
        case 'users':
        params.path = "${command}/${state.user_id}"
        break
        case 'user_feedback':
        case 'devices':
        params.path 	= "${command}"
        params.query 	= ["user_id": state.user_id]
        break
        case 'sprinkler_timer_programs':
        params.path 	= "${command}"
        params.query	= ["device_id" : device_id]
        break
        case 'zone_reports':
        case 'watering_events':
        case 'landscape_descriptions':
        case 'event_logs':
        params.path = "${command}/${device_id}"
        break
        case 'meshes':
        params.path = "${command}/${mesh_id}"
        break
        default :
        log.error "Invalid command '${command}' to execute:"
        return false
    }
    //    log.debug "params = ${params}"
    try {
        httpGet(params) { resp ->
            // log.debug "response data: ${resp.data}"
            if(resp.status == 200) {
                respdata = resp.data
            } else {
                log.error "Fatal Error Status '${resp.status}' from Orbit B•Hyve™ ${command}.  Data='${resp?.data}'"
                return null
            }
        }
    } catch (e) {
        log.error "OrbitGet($command): something went wrong: $e"
        return null
    }
    if (command=='devices') {
        def bridgeCount = respdata.type.count {it==typelist()[1]}
        def bridgeMsg = (bridgeCount==0)?'in your Orbit b•hyve™ account':"and ${bridgeCount} network bridge device(s)"
        state.devices = "Found ${respdata.type.count { it==typelist()[0]}} sprinkler timer(s) ${bridgeMsg}."
        state.timezone = respdata[0].timezone.timezone_id
    }
    return respdata
}

  1. We are in Ohio and rain happens sufficiently enough to keep gardens & grass green. There only a few days where sun is harsh and watering is required to prevent burn out. Water is plenty, but we still try to conserve with minimal watering run-times.

  2. The documentation for the .env fields is in the github’s node readme in the node.js server section.

  3. Sounds like a plan.

BTW, I updated the Readme file in the github node section to:

  • Reference x.x.x for the current tgz version rather than a hardcoded release number.
  • Replace Rapsberry Pi with compatible node.js server in requirements.
  • Changed app startup command to simply node app.js which will automatically include the .env file in the same directory as the app.
90

Ok, I am noticing that the API isn’t reporting to the SmartApp/DTH.

When the sprinkler finishes, it still the tile still says “Open”

Also:
Outdoor -> SKIPPING Event ‘flow_sensor_state_changed’

This is imperative to keeping track of gallons.

I am guessing that the Websocket has not been implemented into the SmartApp yet because the SmartThings log shows everything about what the Websocket is reporting, but doesn’t reflect that change.

I’ll try to get flow_sensor_changed added now.

91

@Tony_B,

I’m not sure what is happening to your install and bhyve devices, but my 5 Orbit Bhyve Hose devices are reporting each time they open/close (several times per day) and showing flow activity when active. I also have have the node proxy install active and it complements the SmartApp’s polling by sending realtime open/close events to ST before the next poll period…

So with or without the install of the node proxy, the ST Orbit bhyve Controller app should be polling the bhyve servers to get device status at whatever frequency you have chosen in the App.

  1. It could be your devices are a different model than mine?
  2. It could be you are using the Android version of ST, or on the new ST mobile client? I am only supporting ST iOS legacy client at this point as my home systems are humming along perfectly, and I am not ready to chance issues with the new ST mobile client.
  3. Perhaps a complete fresh install from scratch, removing/deleting all devices, DTH’s and SmartApp and installing again. This is a pain, but is recommended by tech support and has worked 50% of the time., Go figure, ST mobile client’s can get in a foo-bar state.

My walkout device just fired off, here is what I get in the ST Classic iOS mobile:

IMG_8160
IMG_81601125×2436 408 KB
IMG_8161
IMG_81611125×2436 589 KB
IMG_52A9CAE53F24-1
IMG_52A9CAE53F24-11125×2436 546 KB

image
image2132×332 88.7 KB

92

Does your npm logging show that it’s skipped

like this:
Outdoor -> SKIPPING Event ‘flow_sensor_state_changed’

I added the case in the app.js code and it started to report to SmartThings.

If you don’t have the hose timer, then that would explain things like “water_volume_gal” and “cycle_volume_gal”… I just did a search and replace on these and it still didn’t fix the gallons used on the tile.

EDIT!! OR Because you have more than 1 zone, it does water_volume_gal

If you do have the same, then, Perhaps there might be version differences of the one published to git.

I have the Orbit bhyve hose timer/hub pair with SmartThings Classic on a Google Pixel 2XL.

93

  1. Does your npm logging show that it’s skipped?

    • No, here is my node proxy log for a quick manual on/off test. Note that gallons are not reported unless one taps the bhyve client circle guage like I did… This is a quirk of the oem bhyve client app…

  2. I also added ‘flow_sensor_state_changed’ to my version of the app.js and Orbit bhyve Controller app case statements which will have the affect of causing the Orbit bhyve SmartApp to run a refresh and update the device DTH.

    I do not get these ‘flow_sensor_state_changed’ events in my use so far, so make sure that these ‘flow_sensor_state_changed’ events on the node proxy don’t cause the Orbit bhyve Controller SmartApp to refresh faster than ST allows for Smartapps, or your instance will fail per ST’s stated app run frequency rate policy.

  3. I have the 5 B-hyve Smart Hose Watering Timers and 2 WiFi hubs (Part Number 21004 , 21005). These can only have 1 zone defined in the bhyve oem client.

  4. The iOS and Android ST mobile clients perform and display differently with some custom developed apps, as reported in several of my wide user base and other devlopers. This inconsistency has been a real pain to debug and ST IT engineers do not have an answer for many of the issues I have reported and sent screen shots and logs. To make matters worse, sometimes the Android users even state that they see differences between hardware and OS versions of their family phones, which adds another level of complexity. :rage:

Tue, Jun 16, 2020, 5:28:52 PM - Sending PushOver 'Tue, Jun 16, 2020, 5:28:52 PM - MQTT connected at mqtt://localhost:1883'
Tue, Jun 16, 2020, 5:28:52 PM - STOrbitBhyveController™ Webserver is listening on port: 3000
Tue, Jun 16, 2020, 5:28:52 PM - Pushover Message {"status":1,"request":"69ce4b67-7a69-4168-93b3-79c5676d8415"} sent successfully
Tue, Jun 16, 2020, 5:28:52 PM - Post Accepted Status: 200
Tue, Jun 16, 2020, 5:28:53 PM - All 5 devices are reporting a 'CLOSED' state'
Tue, Jun 16, 2020, 5:28:53 PM - Sending PushOver 'Tue, Jun 16, 2020, 5:28:53 PM - All 5 devices are reporting a 'CLOSED' state''
Tue, Jun 16, 2020, 5:28:53 PM - All Devices -> POSTING Device Updates to SmartThings API
Tue, Jun 16, 2020, 5:28:53 PM - All Orbit Devices -> Executing Client.prototype.smartthings for event: UPDATEALLDEVICES
Tue, Jun 16, 2020, 5:28:53 PM - Sending PushOver 'NODEjs Client.prototype.connectStream'
Tue, Jun 16, 2020, 5:28:54 PM - All Orbit Devices -> ST Post Accepted for UPDATEALLDEVICES
Tue, Jun 16, 2020, 5:28:54 PM - Pushover Message {"status":1,"request":"ce9f6c03-f1b7-48de-8309-6fe08df792c4"} sent successfully
Tue, Jun 16, 2020, 5:28:54 PM - Post Accepted Status: 200
Tue, Jun 16, 2020, 5:28:54 PM - Pushover Message {"status":1,"request":"726a41ba-2e99-4c33-b84f-71744f9d0363"} sent successfully
Tue, Jun 16, 2020, 5:28:54 PM - Post Accepted Status: 200
Tue, Jun 16, 2020, 5:29:34 PM - websocket.readyState = (1), sending keep alive ping #4Tue, Jun 16, 2020, 5:29:34 PM Front - Center  -> message: {"event":"change_mode","mode":"manual","program":false,"stations":[{"station":1,"run_time":2}],"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","timestamp":"Tue, Jun 16, 2020, 5:29:27 PM"}
Tue, Jun 16, 2020, 5:29:34 PM Front - Center  -> SENDING change_mode {"event":"change_mode","mode":"manual","program":null,"stations":[{"station":1,"run_time":2}],"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","timestamp":"2020-06-16T21:29:27.000Z"} to SmartThings
Tue, Jun 16, 2020, 5:29:34 PM - FRONT - CENTER  -> Executing Client.prototype.smartthings for event: CHANGE_MODE
Tue, Jun 16, 2020, 5:29:34 PM Front - Center  -> message: {"event":"watering_in_progress_notification","program":"manual","current_station":1,"run_time":1,"started_watering_station_at":"Tue, Jun 16, 2020, 5:29:26 PM","rain_sensor_hold":false,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","timestamp":"Tue, Jun 16, 2020, 5:29:26 PM"}
Tue, Jun 16, 2020, 5:29:35 PM Front - Center  -> SENDING watering_in_progress_notification {"event":"watering_in_progress_notification","program":"manual","current_station":1,"run_time":1,"started_watering_station_at":"2020-06-16T21:29:26.000Z","rain_sensor_hold":false,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","timestamp":"2020-06-16T21:29:26.000Z"} to SmartThings
Tue, Jun 16, 2020, 5:29:35 PM - FRONT - CENTER  -> Executing Client.prototype.smartthings for event: WATERING_IN_PROGRESS_NOTIFICATION
Tue, Jun 16, 2020, 5:29:35 PM - FRONT - CENTER  -> ST Post Accepted for CHANGE_MODE
Tue, Jun 16, 2020, 5:29:35 PM - FRONT - CENTER  -> ST Post Accepted for WATERING_IN_PROGRESS_NOTIFICATION
Tue, Jun 16, 2020, 5:29:44 PM - websocket.readyState = (1), sending keep alive ping #5Tue, Jun 16, 2020, 5:29:51 PM Front - Center  -> message: {"flow_rate_gpm":0.38402,"cycle_run_time_sec":18,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.527835,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:44 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:29:53 PM Front - Center  -> message: {"flow_rate_gpm":2.87321,"cycle_run_time_sec":19,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.57125,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:45 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:29:54 PM - websocket.readyState = (1), sending keep alive ping #6Tue, Jun 16, 2020, 5:29:54 PM Front - Center  -> message: {"flow_rate_gpm":2.7422,"cycle_run_time_sec":21,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.655795,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:47 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:29:56 PM Front - Center  -> message: {"flow_rate_gpm":2.7422,"cycle_run_time_sec":22,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.696925,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:48 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:29:57 PM Front - Center  -> message: {"flow_rate_gpm":2.7422,"cycle_run_time_sec":24,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.779185,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:50 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:29:59 PM Front - Center  -> message: {"flow_rate_gpm":2.7422,"cycle_run_time_sec":25,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.820315,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:51 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:30:00 PM Front - Center  -> message: {"flow_rate_gpm":2.7422,"cycle_run_time_sec":27,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.902575,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:53 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:30:02 PM Front - Center  -> message: {"flow_rate_gpm":2.7422,"cycle_run_time_sec":28,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"flow_sensor_state_changed","cycle_volume_gal":0.943705,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"timestamp":"Tue, Jun 16, 2020, 5:29:54 PM","gateway-topic":"devices-1"}
Tue, Jun 16, 2020, 5:30:03 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:29:56 PM","event":"watering_complete","stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:03 PM Front - Center  -> SENDING watering_complete {"timestamp":"2020-06-16T21:29:56.000Z","event":"watering_complete","stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"} to SmartThings
Tue, Jun 16, 2020, 5:30:03 PM - FRONT - CENTER  -> Executing Client.prototype.smartthings for event: WATERING_COMPLETE
Tue, Jun 16, 2020, 5:30:04 PM - FRONT - CENTER  -> ST Post Accepted for WATERING_COMPLETE
Tue, Jun 16, 2020, 5:30:04 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:29:56 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:04 PM - websocket.readyState = (1), sending keep alive ping #7Tue, Jun 16, 2020, 5:30:04 PM Front - Center  -> message: {"event":"change_mode","mode":"auto","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","timestamp":"Tue, Jun 16, 2020, 5:29:56 PM"}
Tue, Jun 16, 2020, 5:30:04 PM Front - Center  -> SENDING change_mode {"mode":"auto","program":null,"stations":null,"timestamp":"2020-06-16T21:29:56.000Z","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","event":"change_mode"} to SmartThings
Tue, Jun 16, 2020, 5:30:04 PM - FRONT - CENTER  -> Executing Client.prototype.smartthings for event: CHANGE_MODE
Tue, Jun 16, 2020, 5:30:04 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:29:56 PM","event":"device_idle","stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:04 PM Front - Center  -> message: {"event":"rain_delay","delay":0,"device_id":"xxxxxxxxxxxxxxxxxxxxxxxx","timestamp":"Tue, Jun 16, 2020, 5:29:56 PM"}
Tue, Jun 16, 2020, 5:30:05 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:29:57 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:05 PM - FRONT - CENTER  -> ST Post Accepted for CHANGE_MODE
Tue, Jun 16, 2020, 5:30:06 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:29:59 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:08 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:00 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:09 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:02 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:11 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:03 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:12 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:05 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:14 PM - websocket.readyState = (1), sending keep alive ping #8Tue, Jun 16, 2020, 5:30:14 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:06 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:15 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:08 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:17 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:09 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
Tue, Jun 16, 2020, 5:30:18 PM Front - Center  -> message: {"timestamp":"Tue, Jun 16, 2020, 5:30:11 PM","event":"flow_sensor_state_changed","cycle_run_time_sec":0,"flow_rate_gpm":0.38402,"stream-id":"xxxxxxxxxxxxxxxxxxxxxxxx","client-topics":["device-clients-2"],"gateway-topic":"devices-1","device_id":"xxxxxxxxxxxxxxxxxxxxxxxx"}
94

Ok, there is the programming difference…

You are getting “flow_rate_gpm” and I am getting ‘flow_sensor_state_changed’

In the ST Log:

4:39:47 PM: debug => webEvent #864: 'flow_sensor_state_changed'-> data : [timestamp:2020-06-16T20:39:46.000Z, cycle_run_time_sec:96, client-topics:[device-clients-1], cycle_volume_gal:2.931655, flow_rate_gpm:2.3491699999999995, gateway-topic:devices-1, event:flow_sensor_state_changed, stream-id:xxxxxxxxxxxxxxxxxx, device_id:xxxxxxxxxxxxxxxxxxx]

Your post definitely explains a lot.

On the node log, I get this:

Outdoor -> SENDING flow_sensor_state_changed {"flow_rate_gpm":2.2181599999999997,"cycle_run_time_sec":98,"cycle_volume_gal":2.92937,"timestamp":"2020-06-16T20:46:46.000Z","device_id":"xxxxxxxxx","event":"flow_sensor_state_changed"} to SmartThings

I will try my best to edit the smartapp and you can merge the changes, people installing this in the future can have different setups without having confusion over which Smartapp to use

1 Like
95

Interesting, not sure why we are seeing different events using the same models! HeadBang!

OK, the area you want to change in the Orbit bhyve Controller SmartApp is below and add the new case statement with the :heavy_check_mark: :

case ‘watering_events’:
:heavy_check_mark: case ‘flow_sensor_state_changed’:
case ‘program_changed’:
case ‘watering_in_progress_notification’:
case ‘watering_complete’:
runIn(5, “refresh”)

Add this new case statement to the app.js with the :heavy_check_mark: :

switch (event) {
case ‘program_changed’:
:heavy_check_mark: case ‘flow_sensor_state_changed’:
case ‘watering_complete’:
case ‘watering_in_progress_notification’:
case ‘change_mode’:
case ‘low_battery’:

The Orbit byve Controller SmartApp should really be functioning as expected for sensing without the node proxy server, just not as fast at detecting the on/off watering events since API polling frequency is not real-time from the ST cloud server to bhyve API cloud server using http!

The node proxy server adds faster on/off watering event detection using an open websocket and also has the added benefit of allowing the Orbit bhyve Controller SmartApp to turn a watering device on/off…

Good luck!

96

@kurtsanders These are already in the original code. What do you mean to “add them”?

My question is how to get “flow_sensor_state_changed” to log these events to the tile.

The “flow_sensor_state_changed” might repeat too often, 1 time every 1-3 secs

The ST rules said 100/min, I should be safe.

Thinking about adding a ‘if’ statement for flow sensor state change.

97

The SmartApp will catch the “flow_sensor_state_changed” sent from the proxy node server and create a asynchronous ‘refresh’ event in 5 seconds. This causes the Orbit bhyve Controller SmartApp to connect to the bhyve http api server for ALL device state changes.

I’m not sure what will happen if you cause the Orbit bhyve SmartApp to refresh at a rate faster than say 2-3x per minute, since the http API server takes a few seconds to give the json response back for all the devices and then their is the added processing time for the SmartApp to process the json data for each watering device.

IMHO, I would try to program a throttle of the “flow_sensor_state_changed” events in the node proxy so that you can be assured that the SmartApp refresh event completes and there is some tine in between the next ‘refresh’ call so that you are not polling the bhyve API server with your device and they detect it and block it by device ID or account. If Orbit IT blocks this over polling by IP address, you risk black listing ST cloud which is brokering the http API ‘refresh’ call for all of us.

As much as many of us would love to have SmartThings be ‘real-time’, it is not built for fast updates of the devices, given the nature of their cloud hub implementation. If you want faster processing and device display, I would suggest using a Hubitat server which operates locally. I have several apps that I have migrated to Hubitat since this server can handle very fast events!

98

I took away the “flow_sensor_rate_change” and used status.

A few things need to be touched up but it’s pretty good.

I might have left some commented junk in there, you can delete it.

Problems:
It won’t round because there are brackets surrounding the gallons number. It’s 3am and I gotta get to sleep.

To-Do: Turn it on from the tile. Only allows off.

1 Like
99

@Tony_B I sent you a PM to continue these discussions.

100

I’ve been working on porting your code to another platform (Hubitat) which, nicely has Websockets built in so I don’t need the Node.js stuff and can do everything natively and locally on the hub… Really great work on this, you saved me a lot of time from reverse engineering the Android app! And since Hubitat works with something very similar to ST DTH and SmartApps, porting it was only a few hours of work! Anyway, a couple of questions:

1.) def message = “Orbit device requested to manually OPEN but scheduled_auto_on = false, ignorning request” – what is the purpose of this limitation?
2.) With the node server you have, have you noticed frequent WebSocket disconnects? I’ve noticed that sometimes I get disconnected and then reconnecting doesn’t work when I retry every 30 seconds. I’m now doing a “staggered” retry where it will do retryCount*30s up to a max of 5 minutes.

Figured I’d ask in case you have any insight before I keep troubleshooting.

101

@dman2306

Glad to have you do this conversion, since someday I will port everything I have on SmartThings to HE. The ST platform strategic direction IMHO is getting var too complicated with their elimination of hosted server based SmartApps (groovy) and user defined DTH’s.

  1. I believe that DTH logic check handles when a user has set the ‘Device Run Mode’ set to ‘Off’ in the OEM bhyve App. When I coded this years ago, I found that a bhyve hose device will not turn ON/OPEN until that ‘Device Run Mode’ setting is set to ‘Auto’ mode? I think I experienced this issue when I had some of my bhyve hose devices ‘Device Run Mode’ off, and could not figure out why the WebSocket command to OPEN was not turning the hose device open.

  2. OMG, don’t get me started on the instability of the bhyve WebSocket proxy server… I have the proxy server being auto-restarted using PM2 since it randomly dies, hangs, goes silent, burps, etc with very little notice… Any of my other websocket proxies are rock solid, so I know it is Orbit bhyve servers. I think that the iOS byhve app handles this instability by only being connected for a brief period of time while the user looks at the device’s status and them closes down the app… The dropped connection could also be bhyve’s way of handling load balancing? Hope you can provide resilience in the HE’s websocket, otherwise, users will be disappointed.

I look forward to testing and who knows I might switch to your code stream on HE…

102

Ok cool, I’ll have to play around with that.

Well I guess a good news/bad news. I was kind of hoping you’d say “Nope, super stable!” because then it’d mean I was just doing stuff wrong. I’m getting there, here is what I did so far:

  1. In the app_connection WebSocket method I added orbit_app_id: UUID.randomUUID().toString(), because the Android App seems to send this parameter (the Node.js app didn’t)
  2. When I get disconnected, I also now recall the login endpoint. I figure it will help me handle a case where the token expires (does it???)
  3. If I get disconnected I wait 30 seconds before reconnecting and keep retrying every 30 seconds. So far so good with that. What I really wanted to do was do 30s*#_of_retries but I’m struggling to get that working in HE (they need a websocket.isConnected() method but it doesn’t exist!)

If you’re interested in taking a look, GitHub - dcmeglio/hubitat-orbitbhyve: Provides integration with a Orbit™ Bhyve Timer and SmartThings You’ll notice like 80% of it is the same as your code. Porting ST drivers/apps is mostly straightforward other then there are “Hubitat ways of doing things” where sometimes I recode something that “works” to be a way that is better for HE… and then of course adding extra features like the WebSocket stuff.

I’ve been very happy with HE. Everything that broke in ST (like the Rheem EcoNet integraton that broke because they switched to MQTT which ST doesn’t support) I’ve been able to get working in HE. The biggest negative is now I’m maintaining a billion integrations so if you ever do hop over to HE, feel free to take this integration back over :wink: But yeah, as much as AWS is super cool, I really don’t want to manage my own cloud accounts to run stuff, and even worse, it then means everything I build is just for me because, no, I’m not training others on how to setup AWS accounts and such.

2 Likes