Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ActionValue key errors #1

Open
AaronLionsheep opened this issue Mar 11, 2020 · 23 comments
Open

ActionValue key errors #1

AaronLionsheep opened this issue Mar 11, 2020 · 23 comments

Comments

@AaronLionsheep
Copy link

AaronLionsheep commented Mar 11, 2020

Hey Karl,

I was looking through your code and noticed you had a few typos in the key values for the following:

try: del actionValues["blueevel"]

del actionValues["blueevel"]

And you check for the red color being presented twice instead of checking if green is present:

if "redLevel" in actionValues or "redLevel" in actionValues or "blueLevel" in actionValues:

@kw123
Copy link
Owner

kw123 commented Mar 11, 2020 via email

@AaronLionsheep
Copy link
Author

My goal is to have my plugin also be able to create devices automatically. Once a Shelly is on the network and connected to a broker, you can send a command to ALL Shelly devices on a broker on shellies/command and tell them to announce. They all respond with their address and some other meta-data.

I decided to expose the input switch as two separate states for my devices:

  • sw-input will be either true or false to indicate if the on-board button is currently pressed or not
  • longpress will be either true or false to indicate if the onboard button is being long-pressed.

The separated states decouples the plugin from how the device is configured. Plus it also gives some more flexibility to Indigo since somebody might not care if it is simply on or long-pressed.

As for the add-on sensors, I think they plan to release some more sensors. This is according to CliveS from his post (https://forums.indigodomo.com/viewtopic.php?p=189393#p189393) about the release of new devices.

I REALLY hope they don't remove HTTP and MQTT functionality in the future. I think MQTT is pretty neat. Plus that would mean our plugins would need some major overhauling...

I think the protocol is CoAP (https://en.wikipedia.org/wiki/Constrained_Application_Protocol), which to me looks like Z-Wave over WiFi/UDP. As long as they keep sticking the ESP chip in there, I don't see a reason why they have to remove HTTP and/or MQTT.


I am a student at college (Computer Science). I managed to work my plugin development into a "Technology Community Service" requirement for one of my classes. Now I can work on my plugin instead of "school work" and not feel bad haha! I wonder if Indigo is hiring - I've been exposed to it for over half of my life...

Aaron

@kw123
Copy link
Owner

kw123 commented Mar 11, 2020 via email

@kw123
Copy link
Owner

kw123 commented Mar 11, 2020 via email

@AaronLionsheep
Copy link
Author

There is a single topic that reports both on, off, and long press. So as soon as user releases the button after triggering a long press, both the sw-input and longpress become false.

@kw123
Copy link
Owner

kw123 commented Mar 11, 2020 via email

@AaronLionsheep
Copy link
Author

AaronLionsheep commented Mar 11, 2020

I did the same with the Shelly 2.5. I determined that that device is pretty much two Shelly 1PM's in a single enclosure. So my Shelly 2.5 Indigo device represent half of a Shelly 2.5 and is modeled after the Shelly 1PM. My 2.5 device lets the user specify the "channel" as channel 0 or 1 to identify which relay they will control. I decided to just group a single input switch with a single relay.

Channel x

Each device subscribes to these topics with a 0 or 1 as the x
shellies/shellyswitch25-<deviceid>/input/x for each SW input x
shellies/shellyswitch25-<deviceid>/longpush/x for each SW input x; reports a value indicating longpush state as 0 or 1
shellies/shellyswitch25-<deviceid>/relay/x for each relay x
shellies/shellyswitch25-<deviceid>/relay/x/command for each relay x
shellies/shellyswitch25-<deviceid>/relay/x/power for each relay x
shellies/shellyswitch25-<deviceid>/relay/x/energy for each relay x

Both devices

Both of the indigo devices for a single 2.5 relay will subscribe to these topics since the internal temperature is shared between the two.
shellies/shellyswitch25-<deviceid>/temperature reports internal device temperature in °C
shellies/shellyswitch25-<deviceid>/overtemperature reports 1 when device has overheated, normally 0

Numbering

As for the numbering, they use zero-indexing internally, but just use 1-indexing since that is more user-friendly. I simply just did the following in my "channel selection" part of the device config:

<Field type="menu" id="channel" defaultValue="0">
    <Label>Relay Channel:</Label>
    <List>
        <Option value="0">Channel 1</Option>
        <Option value="1">Channel 2</Option>
     </List>
</Field>

So the user is presented with 1-based indexing and internally I automatically get 0-based indexing.

I actually decided that internally, all devices have "channels", even though the majority of devices are a single channel. These single channel devices have the Chanel selection hidden and just default to 0. My architecture then allows me to build devices off of one another without rewriting too much code (and introducing "undesired features").

For example, my Shelly 2.5 device allows the user to select a channel and only has 30 lines of code since it inherits almost all features from the Shelly 1PM (which inherits the majority of its code from the Shelly 1... and it keeps going). https://github.com/AaronLionsheep/ShellyMQTT/blob/0.6.0/ShellyMQTT.indigoPlugin/Contents/Server%20Plugin/Devices/Relays/Shelly_2_5_Relay.py

If you're interested, take a look at how I was able to structure my device implementations. It seems that most of the Shelly devices are actually built on top of each other, so I tried to model my code this way too.

@kw123
Copy link
Owner

kw123 commented Mar 11, 2020 via email

@kw123
Copy link
Owner

kw123 commented Mar 11, 2020 via email

@kw123
Copy link
Owner

kw123 commented Mar 12, 2020 via email

@AaronLionsheep
Copy link
Author

If it makes you feel any better, I had to use both Fotran and Ada in my last homework assignment for one of my classes. However, my assignment was graded on a 24 node cluster with a total of 960 cores and about 2.2 TB of ram, we've come a long way!

I definitely understand where your style comes from! I have tried to read through some of your other plugins a while back and didn't get very far before my brain had enough.


I had originally planned to use the on/off variants of icons to reflect the online status of devices. For example, the Shelly HT only comes online twice per day, so a grey temperature icon would let the user know that the data could be old. However, it seems like a lot of icons are not "available" in the Indigo UI. I set both of those to "On" icons because the off icon is missing and just defaults to a grey orb.

It seems that a lot of colleges are now moving all classes online. Mine has just done the same today. I'm in my 4th year and I have one semester left in the fall. Maybe I can get one last "normal" semester by then...

Which devices have your ordered from Bulgaria?

@kw123
Copy link
Owner

kw123 commented Mar 12, 2020 via email

@AaronLionsheep
Copy link
Author

Thanks for the offer - I will keep that in mind!

I will be testing with the latest Shelly Duo firmware tomorrow. I think temperature control seems to be supported now (the device would even crash/reboot if you sent temperature data over MQTT sometimes). The Shelly Plug and PlugS seem very interesting, but they only come with the EU-style plugs. Maybe we will se a US-style version in the coming months.

Also, I read somewhere in your documentation that you were looking to add support for the Shelly Button. I misunderstood this product at a glance too, but the Button is just an enclosure for the Shelly 1 and 1PM. It lets you splice the wires to a small appliance cable in order to contain the Shelly device neatly.

@AaronLionsheep
Copy link
Author

I'm not sure if you saw, but Shelly released new firmware on Monday and updated their API page as well. They had a lot of devices missing before. Here is the API for the Door/Window if you'd like to get a head start: https://shelly-api-docs.shelly.cloud/#shelly-door-window-overview

@kw123
Copy link
Owner

kw123 commented Mar 12, 2020 via email

@kw123
Copy link
Owner

kw123 commented Mar 12, 2020 via email

@kw123
Copy link
Owner

kw123 commented Mar 12, 2020 via email

@kw123
Copy link
Owner

kw123 commented Mar 13, 2020 via email

@AaronLionsheep
Copy link
Author

From the information that CliveS has provided me (he already has a Shelly Door/Window), it looks like they call it shellydw.

shellies/shellydw-F3B5E0/sensor/battery is from one of the topics that has device is subscribing to.

@kw123
Copy link
Owner

kw123 commented Mar 14, 2020 via email

@AaronLionsheep
Copy link
Author

Congratulations on your release! I also found managing host/children devices to be tricky. I ended up keeping a "dependency" list when a child would start before a parent. Then I could have the parent start its children after it has started up.

I guess I only have the hostname for the device as that is what my plugin uses to identify individual devices. I'm not using the device type for my internal naming, so hopefully that doesn't hurt me later. I haven't seen a good way to migrate old devices to a new device after changing the device type in the plugin.

As long as the postman keeps delivering new Shelly devices to your door, you'll be fine, right? 😃

@kw123
Copy link
Owner

kw123 commented Mar 15, 2020 via email

@kw123
Copy link
Owner

kw123 commented Mar 21, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants