v3.1.4 (v3.1.5 hot fix, v3.1.6 better fix) moved from beta to production

[sjenkins]

**Update** v3.1.6 better fix for the markdown2 library issue.  Sorry to all for the churn, not self induced

**Update** v3.1.5 is a hot fix as it seems a markdown2 library change messed up the docs
                     (required a minor program change) NO NEED TO INSTALL, JUST FOR DOCS

**Update** v3.1.4 moved to production : didn't hear any complaints about v3.1.4 so moved it to production 

**Update** added docs for garage

So I added the garage device I wanted and integrated it to my Ratgdo device using his ESPhome version.  One day I hope to crack the code on the communications protocol.  For now I have a Home Assistant instance as a man-in-the-middle.  Boy is HA an awful UI environment ; UD feels like a dream after that.  I added the ability to pull / push from variables but didn't put it in the Admin, rather the config, json, or yaml.  Seemed cleaner, I really think the temp devices look messy, I may add some duplicate versions done my way & people can choose.

My TODOS are:
1.  to add docs for the garage device, if anyone else wants to use it. 
2. back-feed my garage plugin improvements to the other devices.  Mostly try, excepts & logging.
3. above idea of duplicate temp devices with variable selection in the config, json, or yaml
4. open to suggestions

Try this out for a few days & then I will put it into production, if no comments are forthcoming.

VERSION = '3.1.6'
"""

3.1.6
FIX better solution to markdown2 issue

3.1.5
FIX repair docs due to markdown2 issue

3.1.4
DONE docs updated for garage

3.1.3
DONE: new device 'garage' door (update to/from variables option)  

3.1.2
DONE: ISY name changes based on updates to config / YAML / JSON

3.1.1
DONE: YAML file option for configuration  
DONE: JSON option for web based configuration  
DONE: Discover button to update based on config updates  

3.1.0
DONE: move version history out of README to own file
DONE: update docs  

3.0.1
DONE fix get value from variable

3.0.0
DONE add control ability to contact device
DONE refactored to modern template

previous updates:
see versionHistory.md

"""
 

Edited June 8 by sjenkins
update to v3.1.4 & move to production & v3.1.5

[hart2hart]

Thanks.  I upgraded production instance to 3.1.4.  Of course devices  are delcared via Standard config:

1 switch

2 switch

3 temperature

...

 

How can/Can I maintain the same devices but include their names by moving them over to JSON config?

[sjenkins]

1 hour ago, hart2hart said:

Thanks.  I upgraded production instance to 3.1.4.  Of course devices  are delcared via Standard config:

1 switch

2 switch

3 temperature

...

 

How can/Can I maintain the same devices but include their names by moving them over to JSON config?

hi @hart2hart,

glad the upgrade worked.

The json & yaml configs have turned out real nice.  For just a few devices the json is good, if you end up with more than three I would suggest the yaml as if you put the file in the right place it can survive a deletion of the plugin.

Hey obviously I can answer your question here, but if you don't mind, I am going to give you an assignment & ask you to look at the docs when you hit the configuration button in the plugin.  Then please give me critical feedback on it.  I still have more to do but am trying to bring the level of the docs up so they get people through the normal flow.

 

[hart2hart]

I found the following line in the Configuration help:

Discovery

• Discover button will add or remove nodes not in one of the configuration methods.

 

..and located the following in one of your other posts:

3.1.2 renaming of nodes based on configuration

ISY nodes to be renamed based on config / YAML / JSON changes
- rename will happen upon restart or Discover
- rename will not happen to default named nodes, where no name was given in the config, so as not to wipe out user renamed nodes in ISY
 

Does that mean the name will not be used since the device was already created and renamed on the eISY?  Regardless, I'll enter the names that I gave them on eISY for "documentation".

 

Also, Does the Discover button only exist under certain circumstances?  I don't see it in the production 3.1.4 version. 

Edited June 7 by hart2hart

[sjenkins]

1 hour ago, hart2hart said:

Discovery

• Discover button will add or remove nodes not in one of the configuration methods.

Does that mean the name will not be used since the device was already created and renamed on the eISY?  Regardless, I'll enter the names that I gave them on eISY for "documentation".

Also, Does the Discover button only exist under certain circumstances?  I don't see it in the production 3.1.4 version. 

@hart2hart , 

Hopefully the json & yaml docs were helpful (I pasted them at the bottom of this for others). Let me know if they were not clear.

Thanks for the above two questions on Discovery:

1. What I mean is that in Discovery node names in the ISY will be renamed if the config name changes in JSON or YAML files.  The basic config has no name given but when initially being made a 'compound' name of the type and id number are given.  This name will NOT be pushed to the ISY so as to not wipe out any changes the user has made to that name.  If you have a more concise way to say that let me know.

1b. If like in your situation a node exists from a basic config & you now goto JSON or YAML config, the name in the config will be pushed to the ISY

2. The discovery button exists in the PG3 screen as well as as a command in the control node for the plugin in the Administration console.  If it's not showing up in PG3 then I think I did not 'tick the box' in the developer list.  This is the first time I have pushed that feature to production (as opposed to beta or local).  I likely missed it.  I will check when I get home ; oops , sorry.

 

Quote

### JSON Configuration

id is optional in the JSON string

````md
Key (var ID)    Value (device type)
  78              {"id": "10", "type": "switch", "name": "switch 10"}
  79              {"type": "dimmer", "name": "main dimmer"}
  80              {"type": "generic", "name": "raw device"}
  82              {"type": "temperature", "name": "lake temperature"}
  85              {"id": "85", "type": "temperaturec", "name": "garden temp"}
  100             {"type": "temperaturecr", "name": "raw temp"}
````

### YAML Configuration

File name without path is within the node directory.
Careful as this file will be deleted with node.
Better to use path and store within admin home directory.
Make sure file permissions are available to node.

````md
Key (var ID)    Value (device type)
  devFile         exampleConfigFile.yaml
  devFile         /home/admin/virtualdevice.yaml
````
 

 

[hart2hart]

@sjenkins The JSON configuration documentation and method are excellent.  For sake of documenting what I have, I "redefined" them using JSON configuration including their names.  I Restarted vs Discovered and all looks great and is functioning well.

Thanks for moving this forward.  I believe there will be many ways to use and expand the node server! in the future now that it has an owner.

[sjenkins]

@hart2hart

discover is now on both the controller node and the pg3 interface.

(didn't click the button on the developer push)

 

[hart2hart]

@sjenkins

Upgraded to 3.1.5 and see the Discover button in PG3 and the updated documentation. They work and are clear.  I have nine virtual switches declared using JSON, so I'll take your advice and look at declaring them with YAML.  Either one is far superior to standard declaration. 

There appears to be a substantial bug in the ratgdo MQTT firmware with security + 2.0 where it randomly stops controlling the garage door but keeps reporting the status values.  It takes a full erase and reflash to fix it.  @Goose66 , that wrote the ratgdo nodeserver, has found where the bug does not appear to exist/been fixed in ESPHome version of the firmware.  If a repaired version of MQTT version is not released soon, I may consider the added complication of installing the HA container on eISY.  Does it make sense that the garage virtual device you've created would provide a simple interface from it providing the equivalent interface to current ratgdo node server via HA?

[sjenkins]

@hart2hart,

yes this is why I was interested in taking on this plugin. The esphome version of ratdgo is way more stable than the mqtt version. Although the HA ui is a nightmare imo once the automations are written they are quick and stable. I am happy to share my automations, my eisy progs, and variables to make this work. 
since putting this into service I am now using remote lock, motion, and other stuff from my opener where I didn’t before. 
let me know how I can help; it’s worked out very well for me. 
 

I put in a pi ha instance but you can put a flask one on your eisy instead. That was just new tech for me which I may go to later. 

[Goose66]

@hart2hart A version of the ratgdo plugin for ESPHome firmware will be completed this weekend and rolled out early next week (probably Tuesday).

[hart2hart]

21 minutes ago, Goose66 said:

@hart2hart A version of the ratgdo plugin for ESPHome firmware will be completed this weekend and rolled out early next week (probably Tuesday).

Have you created a node server that uses the ESPHome firmware -- Damn!  You've put so much into Garage Door node servers.

Edited June 8 by hart2hart

[4481hoods]

Any updates on garage door opener.