rpi_input.py name change?

[George Farris]

Anyone have a problem with me renaming the rpi_input.py interface to
rpi_io.py or rpi_gpio.py? Right now the rpi_input only does inputs on
the Raspberry Pi GPIO pins and I'm going to add outputs as well.

Also it needs some logic added for creating the instance file and
checking which IO mode the Pi might be in (BCM or BOARD) etc.

George

[George Farris]

Ok ignore this, turns out there is a remote_pi interface which is much further along but once again there is no documentation on this.

This is a request to anyone writing an interface or doing a change to Pytomation that is user facing, Please provide documentation. Send it to the list at the very least or me directly, I will add it to the web site.

Unfortunately we now have three Raspberry pi interfaces and none of them are complete. I will work on combining the three into one and call it rpi_gpio unless anyone has any objections.

The raspberry pi stuff should support both local and remote in one interface and allow a user to set GPIO pins to be in or out.

We can then look at maybe depreciating remote_pi, rpi_input and pigpio

Thanks everyone. Thoughts?

George

[David]

No objections; sounds like a plan. I took a quick look at those interfaces a while back; not for anything in particular though. Back then, I found that I'd have to play with them to figure out how they worked and I had greater priorities at the time. It'd be really cool to get those nailed down and documented.

Sounds a bit like our Insteon interfaces; we have 3 of them and none of them are complete (still more complete than most other projects). I'd like to do something similar for Insteon. I think insteon2 should just be removed. It has good code, but it's no where near as far along as insteon or insteon_hub. I like how insteon_hub translates the byte code to objects, making the architecture so much easier to read and understand. insteon_hub handles status messages better in that it really knows what the status messages are, vs just assuming.

I'd like to combine those two. I actually already used a great deal of code in insteon to make insteon_hub. The interface would know it's a hub vs PLM, by the user supplying either the http interface, or serial interface to initialize. I wouldn't take too much to turn insteon_hub into a universal insteon interface that does everything that the current insteon interface does and then some, but I don't have a working PLM at the moment... so that idea is currently tabled.

[George Farris]

Yes I think combining the Insteon stuff into one would be a great idea, and remove the old one alone with Insteon2.

I'll take a look at the hub code and see if it's easy to get to work with my PLM.  

Another alternative would be for me to loan you a PLM to test with.

With the introduction of RpiGpio, I think we can now dump the other RPi stuff as well.

George

--
You received this message because you are subscribed to the Google Groups "pytomation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pytomation+...@googlegroups.com.
To post to this group, send email to pytom...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David]

I added some code to start with the PLM functionality. It's not much, as the hub code is already a combination of the PLM code and the code from insteon_local (just read buffer part), along with my stability tweaks.

The main differences are the hub interface doesn't accept dots in the address, currently (742594, not 74.25.94) and the hub reads the buffer chunks, in a wrapped buffer string, whereas the PLM reads one byte at a time and clears. I think I solved the latter in the new code, but it probably needs to be tweaked a bit; I added that code blindly, to be used as a starting point. The address will also still need to be updated in the instance file.

I think some of the extra insteon functionality, which the main Pytomation system doesn't currently use, like device linking, should also be copied from the current PLM code. I just haven't ever used that code, even with the PLMs, so I forgot it even existed... I'm not even sure if it works in the PLM code, have you had a chance to test it?

That code would come in handy with Interface devices, to control the interface itself (doesn't currently exist). I think we need to add something like that to handle stuff like device linking and interface resets. To handle that though, we'd first need to allow interfaces and devices to contain and use command attributes that's separate from main Pytomation command attributes. That's a big change, so I'll likely table that until we complete the Python 3 stuff, but I think it's something Pytomation needs.

[George Farris]

On Sun, 2018-02-18 at 15:21 -0800, David wrote:
> I added some code to start with the PLM functionality. It's not much,
> as the hub code is already a combination of the PLM code and the code
> from insteon_local (just read buffer part), along with my stability
> tweaks.
>
> The main differences are the hub interface doesn't accept dots in the
> address, currently (742594, not 74.25.94) and the hub reads the
> buffer chunks, in a wrapped buffer string, whereas the PLM reads one
> byte at a time and clears. I think I solved the latter in the new
> code, but it probably needs to be tweaked a bit; I added that code
> blindly, to be used as a starting point. The address will also still
> need to be updated in the instance file.
>
> I think some of the extra insteon functionality, which the main
> Pytomation system doesn't currently use, like device linking, should
> also be copied from the current PLM code. I just haven't ever used
> that code, even with the PLMs, so I forgot it even existed... I'm not
> even sure if it works in the PLM code, have you had a chance to test
> it?
>

I was starting to write the linking code but never finished it. I
actually found I could use the Insteon application in Wine and use it
for linking. It kind of got tabled as it was used in initially setting
the Insteon stuff up but never used after. I understood from the Mr
House guys that Insteon linking is a cluster f**k and doesn't work that
well / takes a long time. But we could look at it again once we get
the PLM and HUB combined. I have the Insteon docs.

If I had to do it over again I would seriously look at Zwave but since
I don't have any Zwave I can't really comment intelligently about it.

[David]

Zwave has it's issues.

I find that I have to reset the interface every once in a while and unplug the controller and plug it back in. This is true in all versions of the driver I've tested.

Also, devices like dimmers don't always give the status updates correctly, unless you have them polled. It's the first issue that's the main problem though.

With Insteon, the main problems are that the controllers like to just die, they don't offer all device types, and a lot of devices that they do offer are more expensive than the Zwave counterpart.

Fully linking the devices can be a hassle for both Zwave and Insteon.

[Jason Sharpee]

I currently have both Insteon and Zwave.   I have Insteon lights and Zwave for everything else.

After doing the capacitor upgrade, the Insteon PLM has been rock solid (years now)

I'm using a closed source zwave driver and it has been reliable as well.  The only thing I don't like is some devices don't participate in mesh (mostly battery operated ones) and some can't use the mesh cause their firmware is limited (extremely annoying).  Then the new protocol z+ tends to behave oddly with the old devices in the mesh as well.  Mostly setup issues though.  I have had to relocate my zwave adapter antenna a lot to get optimal reception.

Great job on the consolidation effort!!

--
You received this message because you are subscribed to the Google Groups "pytomation" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pytomation+unsubscribe@googlegroups.com.